The ConfigMgr product team recently announced support for Windows 7 and Windows 2008 R2 for ConfigMgr 2007 in the form of an update that can be applied to a site server. Great news, but some folk could be forgiven for thinking that Microsoft are providing full support for these platforms now, although the announcement does state that this is not the case.
This is great news for those of us who cannot run ConfigMgr 2007 SP2 RC in production, due to not participating in the TAP program. But, it's important to understand what Microsoft have given us here, limited support for Windows 7 and Windows Server 2008 R2 until full support arrives in the form of ConfigMgr 2007 SP2 RTM.
This is a clear example of the product team listening to its customers, and stepping in with a hotfix to give us platform support right here, right now, before that support is suppose to arrive in the next service pack release. Hat off to the product team for adding functionality to the product ahead of the release timeframes.
When I say limited support of those platforms, I mean you are going to have to wait for SP2 to RTM before you get the following:
- Windows 7 and Windows Server 2008 R2 OS Deployment
- Admin Console access from a Windows 7 client or Windows Server 2008 R2
- Windows Server 2008 R2 hosting site server roles
- BranchCache
- Direct Access
- App-V 4.6 (x64) support
- Future migration to R3
Jeff Wettlaufer, Sr. Technical Product Manager for System Center sums all this up in this posting that clearly explains all this to us.
Keep in mind that ConfigMgr SP2 is expected to RTM in the October timeframe. So we do not have long to wait before we can start managing these two platforms fully within the ConfigMgr product.
And finally, even though this is stated in the above links, worth a regurg here .. if you want to deploy patches to those Windows 7\Windows Server 2008 R2 clients you'll need to upgrade to WSUS 3.0 SP2. I've rolled this out already with no ill effects, the upgrade is seamless, and takes 10-20 minutes to complete depending on how zippy your server is.
I'd strongly urge you to get WSUS 3.0 SP2 out in to your environment now, so that you benefit from the following. The updated Windows Update Agent is worth it's weight in gold, it will support APIs called by non-local system callers in a non-interactive session. If that is sheer gibberish to you then think WUAUCLT /DETECTNOW failing on you whenever you try to force a detection from the command line, you end up seeing this in the windowsupdate log: Windows Update is disabled by policy for user, denied! once you upgrade to WSUS 3.0 SP2 and deploy the new agent, not any more!