The LandPhil be honest, be honorable, be kind, be compassionate, and work hard.

January 26, 2011

Context is everything

Filed under: General — phil @ 6:54 am

I have often been amused at my own ignorance. More than a few times over the past 10 years or so I’ll stop and reflect back on a situation and think, “Wow, I didn’t know a damn thing back then, did I?”

Today, as I perused the giant repository of information called the internet, it struck me again. I’ve been pondering this whole SharePoint thing recently, from the what-business-value-does-it-actually-provide perspective. And I’ve been testing and playing with different aspects of the software. Recently, that has been the My Sites social media experience that they now tout. Now, I have long been of the opinion that social media has no place in the workplace. It is a distraction at best and a productivity killer at worst. I know, I’ve killed my share of productivity. However, it would seem that the business world is moving in this direction. Blogs, tweets, networking, all ways to stay connected…to your business associates. Fine.

This presents a problem, however, when the institution hoping to implement this idea does not have the back end infrastructure to support it. SharePoint is a Microsoft product, and as such, it is tied very heavily into Active Directory. Most places don’t use Active Directory solely as their identity management system as many institutions long ago implemented mainframe systems to house human resources and financials information. Unfortunately, Microsoft has made Active Directory so robust and useful that it’s hard to deny it’s benefits from a systems management standpoint. So, now you have a particular employees information stored in two places: the human resources system and the IT system.

Ideally, you’d only have one system, but that’s never the case. At best, a company will undertake a project to synchronize their multiple directory services. At worst, the two systems never talk to each other. Usually, there’s some hybrid fix that allows limited functionality both directions.

(This is the part where I made the initial “Ah ha!”. See, I’d been at institutions in the past that implemented these synchronization projects, and I’d thought, “What’s the point? The IT folks will keep doing their thing and the human resources/financial folks will keep doing their thing. So, really you’re just making more work for me.” Context is everything.)

So the question becomes, “How does one present the idea that synchronizing a directory system is in the best interests of everyone?” The initial answers are, it isn’t. Like I said previously, neither IT nor human resources will probably immediately take advantage of the integration. In fact, they probably won’t ever take advantage. However, it would make any application development inside of the system infinitely easier on the authentication side. You wouldn’t even need to necessarily change current authentication methods if the systems were synchronized. People could keep using old thing the way they’re used to, but now the data available is more useful and complete.

Here’s the second “Ah ha!” moment. I am not the first person to realize this. Hell, I’m not even in a statistically significant cross-section of the number of people that have already had this thought. But again, it didn’t occur to me prior to now because I wasn’t forced to think about it. Context is everything.

So the next question becomes, “How do I change my context without actually changing my context?” This is clearly an incredibly useful ability to cultivate. Past experience indicates that it’s not possible. I wouldn’t be where I am now had I not actually changed my context. However, I am not naive enough to think it’s not possible. I’m just hoping it’s not another 10 years down the line that I look back and think, “Wow, you didn’t know a damn thing then, did you?”

January 24, 2011

SharePoint: Error, EventID 5586 (and 2159)

Filed under: Errors,SharePoint — phil @ 10:59 am

Log entry for EventID 5586:
Unknown SQL Exception 297 occurred. Additional error information from SQL Server is included below.

 

The user does not have permission to perform this action.

Log entry for EventID 2159:
Event 5586 (SharePoint Foundation) of severity 'Error' occurred xx more time(s) and was suppressed in the event log

What’s going on? This is occurring because your SQL Server has not been configured to use named pipes.

Fix:

  1. Open the SQL Server Configuration Manager (assuming you are using SQL 2008)
  2. Browse down to SQL Server Network Configuration – Protocols for <namedserverinstance>
  3. Right-click “Named Pipes” in the right pane and choose Enable
  4. You may need to restart the server for changes to take effect

> EDIT < Christopher Hatton adds (from the comments):

Granting the farm database access account “VIEW SERVER STATE” under the SQL Server properties will also resolve this issue.

SharePoint: Error, EventID 6482

Filed under: Errors,SharePoint — phil @ 8:14 am

Log entry:
Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (2059dee5-7de2-4e07-ba60-3a5630abdbe1).

Reason: Object 67211af6-bd76-4344-852c-3d331ab57d81-query-0 not found.

Technical Support Details:
System.Collections.Generic.KeyNotFoundException: Object 67211af6-bd76-4344-852c-3d331ab57d81-query-0 not found.
at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize()
at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

What’s going on? The service account specified for “Windows Service – SharePoint Server Search” does not have permissions in DCOM to launch and activate.

The fix:

  1. Go to the Control Panel on the SharePoint application server running search
  2. Launch Component Services
  3. Browse to Component Services – Computers – My Computer – DCOM Config – OSearch14
  4. Right-click OSearch14 and choose Properties
  5. Go to the Security tab and click the first Edit button (under Launch and Activation Permissions)
  6. Add the domain\username of your service account and make sure the check boxes for Local Launch and Local Activation are checked

You should no longer receive Event ID 6482 errors.

SharePoint: Error, Event ID 8213

Filed under: Errors,SharePoint — phil @ 8:02 am

Log entry:
Volume Shadow Copy Service error: The process that hosts the writer with name OSearch14 VSS Writer and ID {0ff1ce14-0201-0000-0000-000000000000} does not run under a user with sufficient access rights. Consider running this process under a local account which is either Local System, Administrator, Network Service, or Local Service.

Operation:
Initializing Writer

Context:
Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
Writer Name: OSearch14 VSS Writer

What’s going on? The account you have designated as the service account for the “Windows Service – SharePoint Server Search” service does not have the correct permissions to the registry keys required for normal operation. By default, this account is the local system or farm account, both of which already have permissions.

The fix:

  1. Open regedt32.exe on the SharePoint application server running search.
  2. Browse to HKLM/System/CurrentControlSet/Services/VSS
  3. Right-click the key VssAccessControl and add a new DWORD (32-bit) value
  4. Name it with the domain\username of the account you have specified as the service account, set the value to 1
  5. Right-click the key Diag and set permissions; add the service account username and grant it full control
  6. At a command prompt run: net stop osearch14. Once the service has stopped, run: net start osearch14.

You can now check the logs and make sure you are no longer getting Event ID 8213 errors.

The generic information for any vss writer application is also available on the german technet site: http://technet.microsoft.com/de-de/library/cc734219(en-us,WS.10).aspx

As an addendum, you may also receive errors with Event ID 12289:
Volume Shadow Copy Service error: Unexpected error RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,...). hr = 0x80070005.

Operation:
Initializing Writer

Context:
Writer Class Id: {0ff1ce14-0201-0000-0000-000000000000}
Writer Name: OSearch14 VSS Writer
Writer Instance ID: {3e52236a-60d3-4ffa-a0ac-22e0f676c972}

You might receive this error if you add the service account value to the VssAccessControl key, but do not also grant them permissions to the Diag key.

January 21, 2011

SharePoint: Office Web Apps – PowerPoint Broadcasting

Filed under: Uncategorized — phil @ 9:05 am

So I thought I’d give the Office Web Apps installation a try, just to see how things worked.  The installation itself is pretty easy.  You may see a lot of stuff go flying by in the SharePoint Configuration Wizard (that you have to run after the Office Web Apps install is finished) that would seem to indicate that it’s creating a bunch of service applications.  Don’t worry, it’s not.  I assume it’s just doing a check to make sure all of the applications that are supposed to be installed are installed.

At any rate, once that was done, I wanted to set up a PowerPoint Broadcast site.  This turned out to be a learning experience, so here are a few gotchas.  The PowerPoint Broadcasting is only available as a site collection template.  I assume there’s probably a way to shoehorn it’s functionality anywhere using Visual Studio or SharePoint Designer, but I just wanted to get it up and running.  So, when you create a site collection, do it then.  Also, when you create the PowerPoint Service Application you can also create a site collection that will be the “default” broadcasting site.  However, if you don’t do it as part of the service application creation process, you can’t add a “default” broadcasting site afterwards.  Live and learn.

January 18, 2011

SharePoint: You’re not the only one that can’t find anything

Filed under: SharePoint — phil @ 9:30 am

I find it amusing that as I delve deeper and deeper into SharePoint, I find that a lot of my questions have been answered.  Unfortunately, it’s not always easy to find them.  Or, they’re actually being documented in near real time to my looking for them.  Or, they’re being discussed at a higher level at conferences and summits occurring, for all intents and purposes, right now.

Microsoft’s TechNet has a LOT of good information, but it’s very vanilla, and in order to answer specific questions you need to sort of piece together the answers out of the information provided.

Specific to actually building a farm, from the administrator’s standpoint, Joan Resnick Ehrlich has a fantastic set of articles that she’s publishing over at NothingButSharePoint.com.  The first one is titled: Life on the Farm: SP2010 Configuration – Prep Work Part 1.

January 11, 2011

SharePoint: Disaster Recovery How-To (SharePoint 2010)

Filed under: SharePoint — phil @ 12:39 pm

No one has a good “How To” out there for Disaster Recovery for SharePoint. Hopefully, this will provide at least a little bit of insight into that process. I will try to document as much as I can the implementation that we’ve decided to use and the steps I’ve gone through to bring it to fruition.

There are many ways that you can set up “disaster recovery” for SharePoint. More than a few of them do it at the SQL Server level. Unfortunately, in order to do that, you need a very fast link between your live SQL servers and your DR SQL servers. We don’t have that link. So, instead, we’re using what’s referred to as the Hot-Standby DR plan. In it, you asynchronously mirror all databases that are supported to be mirrored. This DOES NOT include the SharePoint_Config database, among others. With that in mind, here’s what we did:

First, we set up our production (and development) environments. Once those were done, I installed SharePoint 2010 on the first DR server. I then configured Central Administration for the DR environment using the same steps that we’d used for development and production. Then, I had our SQL DBA configure asynchronous database mirroring between our production SQL and DR SQL servers (for the SQL Admins, that would be high availability, not high safety. The principal database doesn’t wait for changes to commit to the mirror database, for production speed purposes. We also did not configure a witness. Our production and DR sites are in two different data centers, but we do not have a third data center at which a witness could be located. We also didn’t want the overhead or problems associated with the witness being inaccessible at any point.) This is where I believe I made my first error.

I then attempted to rebuild the service applications while pointing the database links to the mirrored databases. For the Business Data Connectivity service application, it worked, but with errors. Those errors were such that I was unable to get into the configuration of the service application itself. So, I removed that service application. I was able to recreate the Managed Metadata Service application in this way, but only by doing it as the exact same user as when it was originally created (that user becomes the term store administrator, by default.) I ran into the same problems with the Secure Store as I did with the BDC.  (Edit:  As it turns out, the Managed Metadata service application didn’t work either.  It worked for me because I had inadvertently mistyped the database name and had created a brand new, non-synced Managed Metadata service.)

It then occurred to me that perhaps doing a granular backup of the service applications in the production environment and then restoring them to the DR environment would work. After a few failed attempts at actually capturing the backups (don’t write directly to a local drive, for whatever reason, some of the files created don’t allow you to write to them. Instead, share a directory and then point to the shared directory instead), I was able to get one. However, when I tried to restore it, I kept running into errors that the databases were already being restored. I believed that to be because of the mirrored nature of the databases.  As luck would have it, I was right.

Ultimately, how I accomplished the DR site was to delete all of the mirrored databases.  Run backup from inside the production central administration of the individual service applications and their proxies and restore those service applications and their proxies to the DR site.  I also backed up the one web application that we had configured and did the same thing.  I thought that perhaps I could do the solutions as well, but I received errors.  You can’t restore a solution to “deployed” status.  Rather, the solutions get copied over and you will need to redeploy them to the target web applications.

The DR site is up.  Things left to do:

  • Document procedures for failing over to the DR site
  • Document procedures for failing BACK over to the production site
  • Test DR site fail procedure

Fun fun fun.

SharePoint: PowerPivot Installation How-To

Filed under: PowerPivot,SharePoint — phil @ 12:33 pm

The first question you have to ask yourself as a new SharePoint administrator in this situation is “What the hell is PowerPivot?” Is it a database? Is it an SQL Server instance? Is it a web application? Is it a service application? The answer to all of those questions is, unfortunately, yes. This makes it sort of complicated.

This all started because we need PowerPivot to chug data for one of the projects I’m involved in. So, of course, it needs to be installed on our farm. Easier said than done.

There was a lot of questions revolving around being able to install PowerPivot on a separate application server in the application layer of the SharePoint architecture. After some poking around, I found some documentation on the subject confirming that it is indeed possible: PowerPivot – Existing Farm Installation (Document)
That’s a handy document to have.

The next step was actually confirming that we could do the installation in an existing farm format. This is where it became truly trying of my patience. The first step is to obtain the SQL Server 2008 R2 media. On the machine you’re going to install PowerPivot, insert the media and launch the SQL installation script. The installation process itself takes forever as the script will run multiple passes of multiple checks to make sure everything is in place to proceed. It is, however, not fool-proof. This means you typically have to wait between 10 and 20 minutes to find out it failed. I’ve been through all of that many times now, so I’ll spare you the headache.

Here are the things that you need to do before running the installation:

  1. Make sure the account you are doing the installation with is the original farm administrator account. It will not work with just any account in the farm administrator’s group. (One of the SQL check phases will fail.)
  2. If you have already installed SharePoint 2010 (which is most likely the case), you will have also already run the pre-requisites installer. This will screw up the SharePoint/PowerPivot integration assembly. Follow the workaround detailed here: http://support.microsoft.com/kb/2261507
    You will be using Method 2. (I had to use Method 1.)
  3. Run the SQL installer.  You will be adding new features.  Choose PowerPivot for SharePoint.  At this point you have to choose between installing in a New Configuration or an Existing Farm.  In order for New Configuration to work, you need to have done the initial SharePoint 2010 installation, but not run the configuration wizard.  If you have a SharePoint_config database already, you are an Existing Farm.
  4. Wait.
  5. Once it completes (preferably with no errors), you will need to create a PowerPivot service application before configuring PowerPivot on your farm.

Powered by WordPress