I am setting up a Microsoft Office SharePoint Server virtual environment for a client and ran into a difficulty that I’d like to share.
First, a brief description of the environment. There are three virtual machines running on Microsoft Virtual PC 2004 Service Pack 1. One is a domain controller, another is a database server running Microsoft SQL Server 2005, and the third is the application server running MOSS. Two service accounts are created on the DC – one for the SQL Server service and the other for the MOSS service. The MOSS service account is defined as a Login in SQL Server and granted dbcreator and securityadmin roles, and is a member of the Local Administrators group on the SQL Server box.
I started with a base Windows Server 2003 Enterprise Edition VM, ensuring all patches we up to date. I created three copies of the VM and brought each one up in series and ran the NEWSID utility, assigning a machine name in the process. Afterwards, I brought up the DC VM and promoted it to domain controller by running DCPROMO. Then I brought up the other two and joined them to the domain.
The SQL Server installation went smoothly with no problems.
The MOSS installation caused me trouble, though, during the final configuration step. During this step, you specify the name of the configuration database server, the name of the configuration database, and the account to use to connect to the database server. Upon specifying this information, a nine step configuration process executes that creates the configuration database, secures the SharePoint installation in the file system, and finalizes the installation.
Unfortunately, the final configuration failed during the step that secures the SharePoint installation in the file system. A series of ACLs are modified by the installer, and one of them bombs out with an exception with message "This access control list is not in canonical form and therefore cannot be modified." A bit of online research revealed a reference blaming this problem on the NEWSID utility, with the following workaround specified:
1. Uninstall Office 2007 SharePoint Server.
2. Unjoin the application server from the domain.
3. On the DC, remove the machine from Computers in Active Directory Users and Computers.
4. Run the SYSPREP utility on the application server. No details were given for this step, so I assume a new SID was to be generated, so I configured the utility to do so.
5. Reboot the application server.
6. Join the application server to the domain.
7. Reinstall Office 2007 SharePoint Server.
I performed all these steps on my server and during the final configuration steps I got a failure at the same point with the same message. So the workaround didn’t work.
I ended up building a server from scratch, thereby avoiding the NEWSID utility, and the installation worked perfectly. I spoke with a colleague about his experience during MOSS installation and he did not encounter this problem, even though he ran the NEWSID utility on his server.
This is still an open issue that would require considerable research to fully understand the interactions involved. If anyone else has any input as to the underlying relationships leading to this problem, I’d be very interested in hearing about it.
For now, I want to put this out there so if anyone else has this problem, they’ll know it is an issue that has been encounted before and can be worked around. Unfortunately, the workaround that worked for me involved several additional hours building and patching a Windows 2003 Server from scratch.
