Archive for the General Category

After quite some requests I’ve spend some time to work out a new task sequence and updated file package for my original post “Configuring Windows RE with MDT 2012 Update 1”. The first version I published back for MDT 2010 required manual configuration in order to work properly, the updated post for MDT 2012 was built on top of that work but re-writing almost everything in order to make it a lot easier to use. I also included a proof-of-concept ready to use WinRE image (a modified WindowsPE image).

This updated version includes a new scenario that I’ve seen many try to implement after finding my post and then stumble upon various issues.

In a nutshell, I’ll describe in short what happens during the task sequence (obviously edits can be make to adjust to your needs)

  • Windows is deployed onto the system, but using a different partition layout: 2 partitions, the first is 10GB and marked as Recovery partition using Type 27, and the second is the remaining volume space for Windows.
  • After Windows has been installed, during the State Restore phase, a script will copy the custom WinRE image to the Recovery partition, and configure windows using ReAgentC.exe to use a custom WinRE environment.
  • Once all the steps in State Restore have been finished, Windows will reboot into WindowsPE (litetouchPE) and capture the Windows installation that was just installed to the Recovery partition.

This allows for very fast recovery of the system if the operating system is really messed up, as long as the bootmgr is still able to boot and the hardware is healthy. This solution is very similar to the recovery partitions that the big brand OEM’s supply with their systems.

The original task sequence I created would sysprep the system before rebooting into PE to capture the image, but this would disjoin the computer from the domain (if joined to a domain), and also cause an OOBE to appear after the task sequence was completed. This scenario would be fine for workgroup computers, or a system builder who wants to provide a recovery solution with their pc’s to their customers. However I’ve been contacted by quite some fellow admins working for large companies also wanting to setup something similar, but not have the machine disjoin from the domain.

The extra task sequence that’s provided in the script file package now actually does just that, it will work for enterprise usage… at a cost (I can’t see a way around this, but we’ll come to that in a minute).

  • Once all the tasks in the state restore phase have been completed, it will move on to the [Custom] Capture Image group, now instead of sysprepping the system it starts a different script.
  • This script does the following: It removes the drive letter R: from the recovery partition (this normally happens during sysprep), remove auto-logon/resume task sequence upon windows logon, re-enable system restore function, remove registry entry for last logged on user; this is not the policy setting “do not display last user name” (that way when the computer boots up for the first time it does not display pcname\administrator) and last.. but most importantly it sets the registry setting to disable the computer password change.
  • After that it reboots into WinPE, and captures the image and it’s done. Once you boot into windows you’re still joined to the domain and if you recover the image right away you’re still joined to the domain.

I would like to point out, that the last item, disabling the computer password change is not a recommended setting. However this is the only way to keep the system joined to the domain without losing it’s AD trust after restoring the recovery image after 30 days (if anyone knows an alternative I’m all ears). If you want to implement a solution like this, I would recommend you to read the following two Technet blog articles:

For more details on the task sequence itself and how to use it (as it’s almost identical to the original one), I’d like to refer to the original post.

The script files and ts.xml files are for download on the technet gallery, and the custom WinRE images are available for download on my skydrive.

Kind regards,

Stephan Schwarz

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

Received MCP Label Pin

By S.Schwarz | Filed in General

Not really related to anything, but I just wanted to show the MCP label pin I received for being one of the first 100 who passed one of the qualifying Microsoft exams after the Cram 4 Exam Marathon held a few weeks back.

It’s always nice to receive small gifts :).

 

 

Cheers,

Stephan Schwarz.

Be the first to comment

This post is about a somewhat hidden option of WDS, which allows you to modify the default behavior the WDS PXE provider/listener.

While this isn’t per se entirely new to everyone, I do find it worth elaborating the uses of this option.

There might be multiple scenario’s where you might find the need to be able to select from which server you actually want to PXE boot from, without specifying with the wdsutil a server that a device should boot to (specify /ReferralServer:<server name>).

The best example I can give you, is that you’re wanting to try to implement System Center Configuration Manager. So lets say you want to try to get to know the product, you’d run it in your lab or test environment which also already has a regular WDS(+MDT; fully optional though) server and it’s used to build your reference images on. Now you could stop the WDS service on that server or shut the server down entirely, but another option would be to allow you to select from which server you want to boot the client pc when it’s doing a PXE boot. There’s one small “requirement” for this setup though,

The “regular” WDS server, which uses the WDS PXE listener, needs to be the server that responds to clients first. So the response delay needs to be lower then the response time of the PXE listener of the SCCM PXE service point. This will ensure that the WDS PXE listener is used to “catch” the clients that are sending out PXE boot requests. Now to enable the usage of the server selection screen, you will need to edit a value in the registry.

You can paste the code below into a text file and save it as .reg to update the value for you, or browse to it manually and edit the value from 0 to 1. After this change the WDS service needs to be restarted.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSPXE\Providers\BINLSVC]
"AllowServerSelection"=dword:00000001

 

Once this change has been made, the next time a client will boot from PXE, the screen will be slightly different. In the first screenshot below, I’ve already pressed F11 to start the discovery of PXE servers. Once it has found all servers, it will bring you to the second screen, notice how it lists the second server as [UNKOWN] ? the reason behind this is because it actually uses a different PXE provider (SMSPXE instead of BINLSVC). And SMSPXE cannot be configured from the registry like BINLSVC can, SMSPXE can only be configured from the SCCM console, and has less options available for configuration. That’s the reason behind leaving the “regular” WDS server as the primary PXE boot server.

 

I hope you found this informative, if you have any questions feel free to email me or leave a comment.

 

Kind regards,

Stephan Schwarz

Be the first to comment

Last week I’ve received an unexpected email from an @microsoft email account, which for some reason found it’s way into my spam mailbox (really, why??).

 

MCC2011 Award

Dear Stephan,

Congratulations! We’re pleased to inform you that your contributions to Microsoft online technical communities have been recognized with the Microsoft Community Contributor Award.

The Microsoft Community Contributor Award is reserved for participants who have made notable contributions in Microsoft online community forums such as TechNet, MSDN and Answers.
The value of these resources is greatly enhanced by participants like you, who voluntarily contribute your time and energy to improve the online community experience for others.

<cut>login information :)</cut>

Thank you for your commitment to Microsoft online technical communities and congratulations again!

Nestor Portillo
Director
Community & Online Support, Microsoft

Receiving such an award means alot to me, and I do feel honoured to be considered as someone who improves the online community experience. It certainly encourages me to keep on helping others
and sharing information whenever I can.

Kind regards and a big thank you,

Stephan Schwarz

Be the first to comment