Archive for June, 2012

While working with my ConfigMgr 2012 lab environment, I figured why not take a look at the new mobile device management capabilities. This would provide me the option to manage mobile devices from within ConfigMgr instead of managing these through Exchange.

When I first tried to configure this setting, I couldn’t get it to work properly since I didn’t entirely know which rights I should give to this new user account that I created for this connector. After trying a couple of combinations, I got it to work; however this was a way to over-privileged account which is far from the desired result. So I began searching again, and found a script on the TechNet Gallery created by the Exchange Team, which created a role group and management roles within Exchange and then adds a user to it, for the Windows Intune Exchange Connector. This was very close to what I was looking for, however Windows Intune requires access to more cmdlets than ConfigMgr does. So I edited the script slightly to reflect the names used for the role group and the management roles for ConfigMgr usage and removed the unnecessary cmdlets. The result is that the user account that will be added to this role group, now only has the minimum rights as needed to perform the device management features from within ConfigMgr 2012.


I’ve uploaded the modified version of this script onto the TechNet library, which you can find at the following location: link.

As for how to configure the Exchange Connector within the ConfigMgr 2012 Console, you can add these from the Administration View > Hierarchy Configuration > Exchange Server Connectors.

  • Click “Add Exchange Server”
  • Specify a CAS server in the format: http://fqdn
  • Click next.
  • For the user account to be used, specify an account to connect to the Exchange Server
  • If you have not already added an account within the Security > Accounts section, you’ll have to add a new account. This account needs to be the same account that was used when executing the script to provision it with the proper user rights.
  • Click next, configure the discovery settings if applicable, then configure the group settings for device management (these pages can be accessed at a later time again by opening the properties of the Exchange Connector).
  • After pressing next at the summary screen, the process will start and add the connector to the management console.


I hope you found this as useful as I did, since it will save me a lot of time anytime I will need to configure this for a lab or demo environment.

Kind regards,

Stephan Schwarz

This post will explain a limitation of cross-architecture deployments of Windows 7 using MDT2012 along with a work-around.

After receiving an email from someone who was having issues deploying a Norwegian version of Windows 7 64-Bit using the LiteTouchPE 32-Bit environment (and had no problems at all when deploying it using LiteTouchPE 64-Bit) I quickly came to the conclusion that the actual setup.exe process that was executed when running in LT-PE x86 was from a set of source files that was from a different language. This is an error that I’ve seen often enough back in MDT2010 where you’d import a new custom .wim image to the deployment share without the setup source files and the image being deployed is actually a different language from those that are already present in the deploymentshare.

Windows Setup Error

This was also one of those topics that came by on the technet forums rather often, and the simple solution was by re-importing the custom image with the setup files (in the appropriate language). However, cross-architecture deployment was not possible back with MDT2010, but now that it is, this very same subject resurfaces again due to the built-in logic of finding setup.exe.

So why does this happen? It’s simple when deploying Windows Vista/7/Server 2008/R2 this will be handled by running setup.exe along with an unattend file, but with a cross-architecture deployment (note: can only deploy x64 from x86, but cannot deploy x86 from x64 PE environments and only works for Windows 7/Server 2008R2) the 64-bit setup files are not able to be executed from a 32-bit PE environment. MDT will look in this scenario for an alternate setup anywhere in the other Operating Systems that have been imported into MDT that did include 32-Bit setup files (note: importing a x64 .wim file and providing 32-bit setup files will still report to MDT as a x64 platform).

At first when I saw this, I thought of a couple of solutions. However, after some more research I’ve came across a post regarding issues deploying Windows 7 with MDT2012 in combination with ADK (this replaces the WAIK/OPK for Windows 8). The following quote is a post of Michael Niehaus [link] (scroll down near to the bottom).

As mentioned before, this is an incompatibility between the beta ADK and Window 7 Setup.exe. This won’t be fixed in ADK or in Windows 7 Setup.exe, so in a future MDT release we will stop using Setup.exe to install Windows, which will avoid the issue.

This issue is also documented in the MDT 2012 release notes. We still suggest using Windows AIK for Windows 7 deployments, unless you are in a lab environment and are willing to put up with small issues like this.

Note that if you import your Windows 7 and Windows Server 2008 R2 images into Workbench without the full source files (just import the Install.wim), then you won’t see this popup when using ADK because MDT 2012 will automatically fall back to using ImageX to install the image instead of Setup.exe. (The change we are making in our next release is to make ImageX the default.)

Now seeing the statement regarding that the default behavior for Windows 7 and Server 2008R2 installations will be handled by ImageX instead of setup.exe, I would personally just suggest to already start planning towards this new change. There’s no drawback for using ImageX.exe vs Setup.exe since offline servicing will still be done after the image has been applied onto the disk (this adds the drivers, LP, patches and such).

I’ve already updated my deployment share that I use for development/testing to reflect this new change, I’ve re-imported all images as plain install.wim files so the entire deployment share does not include any setup files for Windows 7/2008R2 (this can be done for Vista/2008 as well if you wanted to, these do not support cross architecture deployment though). This change also gave me back about 300MB per imported Operating System in my workbench this can add up quickly if you’ve imported a lot of OS’s into the workbench. Note: I don’t even use the ADK yet for this particular share, I still use WAIK to be honest, I prefer this method over running setup, since you gain a time indicator that will tell you how long it’ll take before the image is applied onto the machine, but more importantly the install time is decreased significantly (image being applied within 5 minutes in my lab environment). This is also the method that ConfigMgr 2007 and 2012 apply custom wim images to clients, they dont use setup.exe for that either.

Kind regards,

Stephan Schwarz