Some things to know when installing SharePoint 2007 on Windows Server 2008, plus a little 6482 error talk.
Just working through installing a SharePoint farm on 3 Windows Server 2008 servers and a Windows Server 2003 server for SQL 2005. The 3 Windows Server 2008 servers are two Web Front Ends and an Application server.
There is a set of TechNet instructions specifically for Server 2008 and SharePoint 2007 SP1 here:
http://technet.microsoft.com/en-us/library/cc263408.aspx
Caveats:
IIS 7.0 is installed by default on Windows Server 2008. Additionally, IIS 6.0 compatibility mode must be installed, per the above article (and some experience, now). Here's the text from MS:
"IIS 6.0 Management Compatibility role service
If you use the Windows Server 2008 Server Manager to perform a default Internet Information Services (IIS) 7.0 installation, the IIS 6.0 Management Compatibility role service is not included. Since this is a required role service, you must use the following procedure."
The SP1 slipstreamed version of SharePoint 2007 must be installed. The installation won't even proceed on Server 2008 without this version and will error out if you try. Here are the Technet instructions for this:
http://technet.microsoft.com/en-us/library/cc261890.aspx
There are also multuiple blogs out there on this topic. Just google "slipstream sp1 sharepoint" and there are many results.
We initially installed IIS 6.0 compatibility mode (after adding the "Role" Application Server added IIS 7.0) and then installed SharePoint. As in many farm installations I've seen lately, the 6482, 6398, and 7076 errors starting popping up on the WFE's pretty quick. (These are well-known errors that occur every minute when an SP Timer job tries to update the IIS metabase, which has become locked.) Since these errors are known to be fixed by a hotfix (http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=6003) at KB (http://support.microsoft.com/kb/923028) we went to deploy this hotfix, but it didn't work on Server 2008. We gave Microsoft a call and got the friendly suggestion that, since this error is based on the IIS metabase being locked, maybe we should remove IIS 6.0 compatiblity mode.
This was a bad idea.
The farm went Tango Uniform. Lots of errors started hitting the event log and none of the web apps were accessible. Funny thing, too, the 6482, 6398, and 7076 errors persisted. The MS Rep went real quiet and then advised us we might need to reinstall our farm, but in the meantime, he was going to "repro" our issue. A short while afterwards, he sent us the above TechNet article with instructions for deploying SharePoint on Server 2008. Amazingly, just a few pages in the article explicitly states that IIS 6.0 compatibility mode is required for SharePoint. Guess he didn't read it beforehand.
Anyways, we reinstalled compatibility mode, but only the SharePoint Central Admin and SSP Admin web apps started working again. So, we deleted those web apps from Central Admin (leaving the databases intact), then recreated them in Central Admin with a dummy database name. Once created, we disassociated the dummy database name and reassociated the previous database name and the web apps were fine. Whew.
So, 4 hours lost time thanks to an MS support suggestion we should've thought better of, but some lessons learned, as well.
Other general notes on SharePoint/Server 2008:
Server 08 is built on the Vista User Access Control mindset. You'll hit "Continue" on a dark screen when trying to run many things. You'll also need to run many things as Administrator.
Additionally, Server 08 has fully adopted the Server Manager mindset. Most administration is done through this Server Manager console, which is like a big MMC you built with all the roles as expandable branches in the tree:
All the elements you used to think of as elements that are managed by Management Consoles (MMCs) are grouped under the "Roles" paradigm in Server 2008:
Event Viewer, for example, is inside its own branch called Diagnostics, and defaults to a summary view. The old school Event Viewer is most recognizable in the Windows Logs portion of this tree.
So, a bit clunky at first, it starts to make sense over time and with use.
Specific to IIS 7.0 management, things are a bit different. SSL certs, for example, are handled at the IIS server level, as opposed to per web app. Instead of going into the properties of a web app and selected the Advanced button to apply host headers, the entire terminology and functionality has shifted to a section called Bindings. Here's a shot:
Notice Server certificates (SSL) is now up at the top-level as opposed to managed per web app.
So, in general, things are different in the Windows Server 2008, IIS 7.0 world, but definitely still manageable once you find your way around. Setup of elements such as NLB and IIS 7.0 were quite simple once located.
