Central Administration provisioning fails with System.IO.DirectoryNotFoundException

Question

I recently uninstalled MOSS 2007 from my development server and am trying to reinstall it.

However I get an error during Step 6 of the post-install Configuration Wizard, and this causes the provisioning of the Central Administration website to fail. I've tried uninstalling/installing a few times now and the same thing occurs each time.

The error is...

Failed to provision the SharePoint Central Administration Web Application.

An exception of type System.IO.DirectoryNotFoundException was thrown. Additional exception information: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

Going into the PSCDiagnostics log file I get the following relevant lines:

09/21/2011 15:29:56 8 INF Disabling Kerberos for the provisioned adminvs... 09/21/2011 15:29:59 8 ERR
Task adminvs has failed with an unknown exception 09/21/2011 15:29:59 8 ERR Exception: System.IO.DirectoryNotFoundException: The system cannot find the path specified. (Exception from HRESULT: 0x80070003) at System.DirectoryServices.Interop.UnsafeNativeMethods.IAds.SetInfo()
at System.DirectoryServices.DirectoryEntry.CommitChanges() at Microsoft.SharePoint.Administration.SPMetabaseObject.Provision() at Microsoft.SharePoint.Administration.SPProvisioningAssistant.CreateVirtualDirectories(SPIisWebSite site, Object[][] virtualDirectories) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.CreateVirtualDirectories(SPIisWebSite site, Boolean adminSite) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DoAdditionalWssWebApplicationProvisioning(SPIisSettings[] settingsCollection, Boolean adminSite) at Microsoft.SharePoint.Administration.SPWebApplication.ProvisionIisWebSitesAsAdministrator() at Microsoft.SharePoint.Administration.SPWebApplication.ProvisionIisWebSites() at Microsoft.SharePoint.Administration.SPWebApplication.Provision()
at Microsoft.SharePoint.Administration.SPAdministrationWebApplication.Provision() at Microsoft.SharePoint.Administration.SPWebServiceInstance.Provision()
at Microsoft.SharePoint.PostSetupConfiguration.CentralAdministrationSiteTask.ProvisionAdminVs() at Microsoft.SharePoint.PostSetupConfiguration.CentralAdministrationSiteTask.Run() at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

Checking in IIS, I can see that an application pool and a site (both called SharePoint Central Administration v3) have been created. The folder on the filesystem for the site is created, but it is empty.

I get all the same problems if I try provisioning CA with psconfig, e.g.

psconfig -cmd adminvs -provision -port 9090 -windowsauthprovider onlyusentlm

Any ideas what might be happening?

---

UPDATE: Looking in the SharePoint ULS logs, I see the following relevant messages:

High        Provisioning the metabase path, IIS://localhost/w3svc/154067106  
Medium      Invoking metabase method start.  
Unexpected  Unable to invoke metabase method start:  
            System.Reflection.TargetInvocationException: 
            Exception has been thrown by the target of an invocation. --->  
            System.Runtime.InteropServices.COMException (0x800710D8): 
               The object identifier does not represent a valid object. 
               (Exception from HRESULT: 0x800710D8)     
               --- End of inner exception stack trace ---     
            at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args)     
            at Microsoft.SharePoint.Administration.SPMetabaseObject.InvokeMethod(String method)

Answer 1

Well after a hiatus I returned to this issue and managed to resolve it somehow. I can't fully put my finger on what the issue was, but I'll try to document some of the things I did in case it's of use for some future person.

I uninstalled SharePoint through the Control Panel, but also did the manual uninstall steps listed in in this article, basically ensuring all the relevant entries were removed from the registry and directories removed from the file system.

I also edited the hosts file so it only had one entry, 127.0.0.1 localhost. It had had some custom entries added.

I then restarted the machine, and ran the post install config again... and it failed, again.

I noticed that SharePoint does a weird thing with the ports when you're provisioning Central Admin. Whatever port number you choose during config, it creates the virtual directory in IIS using some other random port number. Also, when the provisioning failed halfway through, I noticed in IIS that the site was bound to this same random port number. Looking at the decompiled code for psconfig.exe and Microsoft.SharePoint.dll in dotPeek it looks like this port is changed to the port you selected after some initial provisioning steps using that random port number.

There's a registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0\WSS called CentralAdministrationURL. This was set to http://<servername>:12345, where 12345 represents the random port number that SharePoint conjures up out of nowhere. So I edited that registry setting to use the port number I knew I was going to choose when I ran the config.

Then I ran the config, this time with psconfig:

psconfig.exe -cmd adminvs -provision -port 8080 -windowsauthprovider onlyusentlm

This time it worked. I'm not really certain which step was the one that fixed it, because I did try some of these steps various times. Maybe this time I did it in just the right order for it to get resolved.

(One other thing I did do, although this one is most likely completely unrelated, is add the 'Services for Network File System Tools' feature to the server through Server Manager, just because I noticed a live SP server that was working fine had this enabled whereas my dev one didn't.)

Answer 2

You can use an old friend here, Sysinternals Process Monitor.

Run it on your system. You can filter it to lock only on your specific process. If you run PSConfig from the cmd window, just use the target looking icon, drag it to the shell window and it will isolate on processes executed from that process.

It will then report on all file, registry, and process calls. You should be able to watch what is happening, and correlate when the job fails with what is happening inside process explorer. Look for fails writing to the file system or registry. With some luck this should be enough to determine your actual cause and correct it.