Earlier today I ran across a strange installation problem and I wanted to share my findings…
The core scenario was about as generic as they come for a single-server farm.
Base line scenario:
Windows 8 with Hyper-V
Windows 2012 Standard guest
SQL 2012 Standard
The deployment plan was straightforward. Use Windows deployment services to provision out a new server, then install SQL, then install the SharePoint prerequisites, then roll out SP and provision. It should have been super fast and easy.
Well, as we all know, SharePoint always tries to makes life interesting. 🙂
Installation failed with a super descriptive error:
"SharePoint Server 2013 encountered an error during setup"
Time to dive into the logs… They pretty much told me nothing at first. The logs reported
"Error: Failed to install product: C:<installFolder>globaloserver.MSI ErrorCode: 1603(0x643)"
Definitely a better message, but it didn’t quite help either.
Time to rollback to the snapshot taken after the prereq’s were installed. Try again. Fail.
The piece the really helped was the Windows error reporting information that was available after dismissing the SharePoint installation dialog.
Error code FC73469E lead me to an insightful post. Sure enough, the VM preparation steps omitted the proper CPU count.
Roll back to the prereq snapshot, up the CPU count, take another snapshot. Install. #FailAgain
Same error. Same log entries. No progress…
Further research showed that others had also documented this problem and some were pointing at a MSI hack left as a comment on a msdn blog post. Maybe I’m old fashioned but msi hacks ain’t right.
Looked over the logs, checked permissions, checked the sql installation, changed install accounts, move the install media to a new location, checked the software prereqs … reviewed the prereq logs… lots of installs failed.
Then it dawned on me that all my attempts to resolve the problem started from the same base configuration – I used the prerequisiteinstaller on the image that had the wrong CPU count. I had "corrected" the CPU problem by changing the VM with the prereqs, then using that snapshot as the base.
The next and last test was rolling back to a clean server, updating the CPU count and *then* installing the prerequisites.
Net net: The prerequisiteinstaller recorded information about the wrong CPU state, which then forced the installer to choke. No msi hacks were necessary (yeah!), only a clean *proper* vm state.
I should have reverted to a clean state once I determined the core state had been compromised. Instead, I "cheated" by going back to a snapshot that incorporated the "faulty" prereq’s … and that in the long run cost me a lot of time.Tags Administration, SharePoint 2013