OS for SCCM Install – revisited
Last October I gathered a lot of info about whether it was better to install SCCM on a 32 bit or 64 bit OS. My post at that time concluded that installing on 64 bit was possibly the better choice, and that was the direction that I went.
Over the last weekend while I was in Bristol with Tim, we got to discussing this issue. He had just uploaded a post to his blog reversing his original opinion that x64 was the best route. His post had some pretty good reasoning in it…in particular the fact that when monitoring SCCM using SCOM, the “SCOM agent will not be able to correctly monitor the 32 bit SCCM processes running on the x64 system.”
Wonderful. At this point, we don’t have SCOM set up in our environment, but I know it is coming. I will probably be looking into transitioning my SCCM install off of the x64 OS as a result. I’m currently downloading the ISO for Windows Server 2008 (32 bit) from our MVLS site. Not a major rush because of monitoring, but I would rather go ahead and make this transition before I move the rest of our clients (approximately 900 workstations) from our SMS 2003 system over to SCCM.
This will also allow me to do a real world test of my disaster recovery plan for my SCCM environment.
while considering the 32vs64 issue for our new implementation, we got this advice from a consultant that you may wish to consider:
My recommendation is that you deploy all SCCM roles on Windows Server 2008 x64 only. The main reason is Microsoft has publically stated it is done with 32-bit servers. So, when Windows Server 2008 R2 is released in September, it will be a 64-bit only OS. If you are running Windows Server 2008 x64, the move up to R2 is really easy – just a quick installation update like you had with Windows Server 2003 R2. If you run the 32-bit version, then you will need to fully rebuild the server to move up to the Windows Server 2008 R2 release.
The next reason to use x64 is better use of memory space. This is important as your central and primary sites will need more than 4 GB of memory and 32-bit versions just don’t handle this well.
The only reason to consider 32-bit is due to the SCCM and SCOM agent conflict that happens when both agents on the SCCM server are running with 64-bit agents. SCOM is capable of monitoring everything on the machine except it cannot get good counters and details on some of the SCCM items. SCCM 2007 SP2 will fix this issue. Microsoft’s official word is that is coming in late 2009. However, the internal release schedules are putting SP2 as close as possible to the Windows 7 release as SCCM 2007 SP2 is needed to fully support the automated deployments and installations of Windows 7. Now, Windows 7 is expected to RTM in late August or early September. So, that will push the release of SCCM 2007 SP2 and MDT 2010 to be around September.
So, your impact until September is any of the SCCM servers deployed will not present the detailed counters to SCOM. I assume you will not have SCOM agents on your desktops right away, so there is no issue there. Then, I assume you will not have SCCM agents fully on servers before September as clients are first from my guess. And, even if you did do servers with SCCM, the only impact is SCOM can’t get at the SCCM specific counters. SCOM can still monitor and manage all other components. Even on the SCCM servers, SCOM can still monitor and manage the operating system, databases, services, etc. The only impact is SCCM-specific counters on SCCM specific servers.
So, the long-winded answer is run Windows Server 2008 x64 on your servers. And, as a matter of practice, you should no longer use 32-bit versions of Windows Server unless you have an application that mandates this.
Good info chief. As with nearly anything related to technology…the “best” advice can change over the course of a year! (this post was written March 2008) Server 2008 R2 was little more than vaporware at the time…heck I’m pretty sure Server 2008 had just RTM’d!
Even a year ago, there were very valid reasons to consider either 32bit or 64bit. The R2 only being 64bit argument is pretty compelling. Thanks for passing this along.