Home > Sharepoint > Sharepoint Problems from Reboot

Sharepoint Problems from Reboot

Or, how I spent my Thanksgiving ‘vacation’.

In our environment, we have our Sharepoint servers using the Microsoft Rights Management Server SP2 for rights management of documents we post to certain libraries in Sharepoint. This has been working fine for months.

Last Monday night I rebooted the servers in futile attempt to get the External Collaboration Toolkit for Sharepoint installed (more on that later). This didn’t resolve that issue, but apparently caused a huge problem that ended up with me spending most of my weekend on the phone with Microsoft support. Numerous people wanted to head out of town for the Thanksgiving weekend here in the US, and had to update documents in a particular RM-enabled library; also, auditors needed to start uploading documents to a new RM-enabled library first thing Monday morning. So, Severity A ticket it is.

If you’ve called MS with a Sev A problem, you know you’re committed to being on the phone with them, or available by phone, 24×7 until the problem is resolved. Happy Thanksgiving!

This manifested itself as anyone trying to open one of the documents would get the usual dialog box (read or edit). Regardless of the choice, your desktop will then try to open the document in the appropriate application after making sure, based on a response form the RM server, whether or not you could. In this case it would sputter for a few seconds, then tell you the document doesn’t exist.

After going through checking the folder C:\Documents and Settings\All Users\Application Data\Microsoft\DRM\Server, and double-checked the ownership of that folder, it still would not go (this is the folder where the MOSS server stores the cerficates it gets from the RM server). We also tried uninstalling and re-instaling the RMS client, de-activating and re-activing RMS on the farm, and a lot more stuff I don’t even remember. We also checked the permissions on c:\documents and settings\all users\application data\microsoft\crypto\rsa\machinekeys, and it looked fine, but more on that later.

The kicker was that this was happening on both the servers I had rebooted, and it did not occur on the two servers I didn’t reboot. The only other difference between the working and non-working servers was that the working ones were pretty new; the other ones had been built over a year ago. Unfortunately, it looked like a server rebuild on the older servers was in order. One of the things we also tried was completely uninstalling MOSS from one of the servers, re-installing it as a stand-alone farm still using the external SQL server, but with new databases. That setup wouldn’t even let me enable RMS on the farm.

So, we made the decision – we would re-do the network so that requests for the main MOSS URL would go to one of the working servers that would serve up requests for that site for the time being. At the beginning of the week I would uninstall MOSS again from that one server, and re-install it as a true stand-alone server complete with SQL Express. That way I could take a backup of that server, and send it off as one image for the MS folks to restore and do further testing on.

In trying to configure this new install, I ran in to a problem where it kept erroring out trying to do the configuration, and was tripping up on encryption. Sound familiar? Per the recommendation of the fine support folks at MS (and I mean that with no sarcasm), I checked on that directory above, the one ending with MachineKeys. Lo and behold, the permissions were borked on it – local administrators didn’t even have access. Once I restored that, I found I could not only configure the server, I could bring up the farm configuration, enable RMS on the farm, create a new document library, enable it for RMS, then add a document to that library, and read or edit that document without an issue.

Problem solved! The root problem was that the server never could get the necessary certificates in the c:\documents and settings\all users\application data\microsoft\drm\server\(long guid). After making sure the permissions were good on the MachineKeys directory:

Add Local Administrators – Full
Add NETWORK SERVICE – Read
Add MOSS Service account – Read

then MOSS was able to connect to the RMS box and get the certs just fine. So, problem solved. Oy.

Also, in trying to uninstall that stand-alone configuration, it kept balking at the beginning, saying it could not find C:\Program Files (x86)\Microsoft SQL Server\90\Setup Bootstrap\setup.ini. At MS’ suggestion, I simply created a blank setup.ini file in that place. Voila! Server uninstalled.

Categories: Sharepoint Tags: