Recently, I ran into an interesting issue.  I thought I’ll post this as I guess most SharePoint Developers could possibly run into it.

I used to have my MOSS 2007 development environment on one domain (let’s say mydomain1.com).  I then joined my development environment to another domain (let’s call it mydomain2.com).  Now, after ensuring that all services etc., are updated with a service account from mydomain2.com, I deleted all the SharePoint databases and ran the SharePoint Technologies and Configuration Wizard only to see the below error:

01/15/2010 21:21:17  8  INF                      Creating a new farm with config db SharePoint_Config content db SharePoint_AdminContent_9a199cb4-40bf-49a5-9dd2-f8e8b679e86a server spdevmoss for farm mode
01/15/2010 21:21:30  8  ERR                      Task configdb has failed with an unknown exception
01/15/2010 21:21:30  8  ERR                      Exception: System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.
   at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.NTAccount.Translate(Type targetType)
   at Microsoft.SharePoint.Administration.SPProcessIdentity.GetCurrentSecurityIdentifier()
   at Microsoft.SharePoint.Administration.SPProcessIdentity.GetCurrentSid()
   at Microsoft.SharePoint.Administration.SPProcessIdentity.Update()
   at Microsoft.SharePoint.Administration.SPApplicationPool.Update()
   at Microsoft.SharePoint.Administration.SPWebApplication.CreateDefaultInstance(SPWebService service, Guid id, String applicationPoolId, IdentityType identityType, String applicationPoolUsername, SecureString applicationPoolPassword, String iisServerComment, Boolean secureSocketsLayer, String iisHostHeader, Int32 iisPort, Boolean iisAllowAnonymous, DirectoryInfo iisRootDirectory, Uri defaultZoneUri, Boolean iisEnsureNTLM, Boolean createDatabase, String databaseServer, String databaseName, String databaseUsername, String databasePassword, SPSearchServiceInstance searchServiceInstance, Boolean isPaired, Boolean autoActivateFeatures)
   at Microsoft.SharePoint.Administration.SPAdministrationWebApplication.CreateDefaultInstance(SqlConnectionStringBuilder administrationContentDatabase, SPWebService adminService, IdentityType identityType, String farmUser, SecureString farmPassword)
   at Microsoft.SharePoint.Administration.SPFarm.CreateAdministrationWebService(SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)
   at Microsoft.SharePoint.Administration.SPFarm.CreateBasicServices(SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)
   at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder configurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, IdentityType identityType, String farmUser, SecureString farmPassword)
   at Microsoft.SharePoint.Administration.SPFarm.Create(SqlConnectionStringBuilder configurationDatabase, SqlConnectionStringBuilder administrationContentDatabase, String farmUser, SecureString farmPassword)
   at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.CreateOrConnectConfigDb()
   at Microsoft.SharePoint.PostSetupConfiguration.ConfigurationDatabaseTask.Run()
   at Microsoft.SharePoint.PostSetupConfiguration.TaskThread.ExecuteTask()

Now, there might be a few resolutions to fixing this.  But I am posting the one that worked for me and I think most SharePoint 2007 developers will run into.

I had, as most SharePoint developers do, got Visual Studio Extensions for WSS 3.0 installed on my development environment.  I should have realized it earlier.  But when we install the VS 2008 extensions, it creates a web site called “VSeWSS” in IIS and uses the “SharePoint Central Administration V3” application pool for it.  Ideally, when we run SharePoint Technologies and Configuration Wizard, it would also delete all the associated applications/application pools in the farm.  However, when we have VSeWSS installed, the “SharePoint Central Administration v3” application pool never gets deleted.  This is probably because there’s still a web site “VSeWSS” that uses this application pool.  And so, when we re-run the SharePoint Technologies and Configuration Wizard, we end up with the above error.

Fixing this is pretty simple, just change the application pool “VSeWSS” uses to another application pool for the time being (I switched it to “DefaultAppPool”).  And then delete “SharePoint Central Administration v3” application pool.  Re-run SharePoint Technologies and Configuration Wizard and it would complete successfully!