By Johan Arwidmark
Microsoft MVP – ConfigMgr
I bet that few of you missed the ConfigMgr 2012 SP1 beta announcement on September 10. Of course the beta is not for production, but there are so many goodies in this release so I encourage you to start playing with them in a lab. Among the updates in SP1 beta you find the following:
· Support for Windows Server 2012 and Windows 8. Not only support for deploying Windows 8 and Windows Server 2012, but also to run site server roles on Windows Server 2012.
· SQL Server 2012 Support. Supporting for running the primary site server (don’t use a CAS, ever, unless you have more than 100 000 clients), on SQL Server 2012 with CU2 or higher
· Distribution point for Windows Azure. Yes, you read it right, you can have a DP in Azure
· Administration via PowerShell. The single coolest feature ever to ConfigMgr. A bunch of cmdlets to ConfigMgr admin work via PowerShell. Just click the Application menu, and then select Connect via Windows PowerShell.
Listing the commands in the ConfigurationManager module.
· Management of Mac OS X and Linux/UNIX. Deploying applications, configuring settings, antivirus, inventory and more.
· Migration from CM 2012 SP1. You can easily migrate objects between primary sites, perfect for
· Interop with Windows Intune. You can integrate with Windows Intune, managing both Intune and ConfigMgr clients
· Configure folder redirection, offline files, and roaming profiles. Basically managing Windows RT devices, which are not domain joined, via ConfigMgr.
· Multiple software update points per site.
· Client notification from the CM Console. Being able to do instant work items from the console, scanning a client for virus, trigger a policy refresh etc. Think right-click tools J
· Email alerts. Not only for Endpoint Protection anymore, but for all alerts.
· PXE Support Defaults. You don’t have to modify the boot images when enabling PXE on your DP.
· WinPE Components. You can list the WinPE components in the boot image properties.
· Task Sequence Deployment Types. When deploying a Task Sequence, you can set who can see the deployment, for example only make it visible from WinPE.
· Deploy Windows To Go. Creating Windows To Go media from ConfigMgr 2012.
· Windows 8 applications. Deploy standalone applications (.appx files) and links to the Windows Store.
Get the lab going!
To help you get your lab going I have created a hydration kit, a download for deploying a complete ConfigMgr 2012 SP1 Beta infrastructure running on Windows Server 2012 and SQL Server 2012 in either Hyper-V or VMware: One Domain Controller and one ConfigMgr 2012 SP1 Beta member server – Including pre-requisites like .Net Framework, SQL Server 2012 CU2 (or higher) and IIS - all fully automated.
Once configured, the total build time for the full ConfigMgr 2012 SP1 Beta lab environment is about 2 hours (on a decent laptop).
To build the lab there are three steps you need to do
1. Download the necessary software
2. Prepare the Hydration Environment
3. Deploy the virtual machines
Detailed instructions are found in this article:
The Hydration Kit for ConfigMgr 2012 SP1 Beta (with Windows Server 2012 / SQL Server 2012) is available for download
The CM01 task sequence, deploying ConfigMgr 2012 SP1 Beta on Windows Server 2012.
Multi forest support in ConfigMgr 2012 Part ll - There can only be one Network access Account.......or.........
In part one I explained how you can get support for clients that are installed in an untrusted forest. In this post I’ll explain a slightly different scenario with two untrusted forest and local site systems installed in the untrusted forest. There is full support for installing user facing site system roles like a Management Point and a Distribution Point. The problem with installing a Distribution point in the untrusted forest is the Network Access Account. This account is being used when deploying operating systems and in some scenarios when clients are accessing the distribution point. Without a trust this process will fail due to the fact that the ConfigMgr agent will connect using the network access account created in the same forest as the primary site server.
Use Multiple Network Access Accounts
The solution is to create a local account on each Distribution Point with the same password. Instead of writing the name of the distribution point (which you cannot because you have multiple DP’s) I specify a variable which I will later create on the clients. Below is my account which is %SMSDPNetbios%\CM_NAA.
How to implement multiple network access accounts
The trick is to figure out what DP will be used by the client and to create the %SMSDPNetbios% and match that with the local Distribution Point. To solve that challange I use use this script (huge thanks to Claus Codam for assisting with the script) which will find the local DP and automatically create the variable on the client. That way the ConfigMgr client will use the local account on the DP server when accessing the distribution point.
How to implement the solution
You must run the script twice in order to get OSD running, first time while being in WIN PE and the second time when you boot into the “correct” operating system. To run the script in WIN PE add it to your boot image and create a prestart command like this cscript.exe GetDPNetbios.vbs 1 The script will read the smsts.log file and get the DP from the log file and create the environment variable. Once you have restarted in Windows create a run command step cscript.exe GetDPNetbios.vbs 2 This will once again create the environment variable but this time in the Windows operating system.