TechEd in Berlin was as hectic as it could be for our instructors. Mikael and Johan did not only do the Pre-Conf days but also multiple regular sessions. I hope those of you that were in Berlin, took the opportunity to attend their sessions and I hope you did not miss Marcus and his security session. If you missed them, they are now uploaded on TechEd online. You will also find links from our website.
We have launched our new web site and we hope you like it. It is broken into one black and one white section. Black being our Security services and the white section holds our Infrastructure trainings and services.
Both Mikael and Johan will run deployment labs in Waltham, MA next week. This is the last chance to attend their labs in 2010, and there are still a few seats available.
Find the schedule as usual at the bottom of the mail.
Back to basics - Understanding Unattend.xml automation in Windows 7
If your goal is to very quickly have a nice fully automated Windows 7 setup, including drivers, application etc. - This article is not for you. If that's your goal, you should download the free Microsoft Deployment Toolkit (MDT) 2010, and use that as your deployment solution.
That being said, if you rather is a hardcore geek who wants to build everything yourself from scratch, instead of using the standard tools that Microsoft recommends, this article will help you create your own answer files to automate the core Windows 7 setup.
This is also your chance to challenge the 20+ people strong deployment team at Microsoft, showing them that you are better building deployment solutions than they are. Why use a standard solution that 300.000 other people on this planet are already using when you can re-invent what they have done and build it yourself.
So here is the text to get in touch with your inner deployment geek...
Download the sample files:
Understanding Unattend.xml automation in Windows 7
The core setup of Windows 7 can be automated by creating an answer file, the Unattend.xml file. The Unattend.xml for Windows 7 (and Vista/2008/2008R2) are divided into sections, or configuration passes. This is because different parts of the setup are reading settings from different passes.
This means that depending on what type of Windows 7 setup you are doing, you need to populate different sections in the answer file. The premium tool for editing the unattend.xml file is Windows System Image Manager (WSIM) from the Windows Automated Installation Kit (WAIK).
The settings that you have to define also depends on if you are using setup.exe to deploy Windows 7, or just using an image utility like ImageX (or ghost, or whatever) to apply an image. I will cover all these scenarios.
Please also notice that you need different answers files depending on what platform (x86 and x64) you are deploying. An answer file for x86 cannot be used for x64 and vice versa.
Scenario 1 - Running setup.exe to deploy Windows 7.
If you boot the default Windows 7 DVD - Setup.exe starts automatically. To have setup.exe pick up an answer file, we just need to named it AutoUnattend.xml and store it in one of the paths that setup.exe looks for answer files in. The most common location is a removable media like a USB stick.
In the sample files for this article you will find a minimal, but fully automated answer file for this scenario. The sample file is for the x86 version of Windows 7 Enterprise when using KMS for activation, joining a WORKGROUP (no Product Key specified in the answer file).
Scenario 2 - Running Imagex to deploy Windows 7.
As mentioned you don't need to run setup.exe to deploy windows 7, you can boot into a WinPE 3.0 environment and use tools like imagex to apply an image. If you don't use setup, you need to also create and format the drive before applying the image. The overall process is the following:
1. Boot on WinPE 3.0
2. Create and format a partition (C:)
3. Use ImageX to apply a previously sysprepped image to C:\
4. Create a bootloader
5. Copy your unattend.xml file (named Unattend.xml) to C:\Windows\System32\Sysprep
In the sample file for this scenario, I have taken the sample file from Scenario 1 and just removed the WinPE pass settings. I could have used the exact same file, for any settings in WinPE pass are simple skipped when using ImageX, but I prefer to have as clean answer files as possible.
Scenario 3 - Running sysprep
You can also prebake the answer file into your image when running sysprep. If you do that, you don't have to copy it in step 4 in the previous scenario.
The sample file for this scenario are the same as for scenario 2. You can have sysprep use it by either specify /unattend:<path-to-file> when running sysprep. Or by storing the unattend.xml file (named Unattend.xml) in the C:\Windows\System32\Sysprep folder before running sysprep. The normal switches for sysprep are /oobe /generalize /shutdown (or /reboot).If we wanted we could also add settings for the Generalize pass for this scenario if we wanted. That section is being read when executing sysprep.
Notes about the answer files.
In Windows 7 the Administrator account is disabled by default. It can be enabled by either specifying the AdministratorPassword value together with Autologon settings, or like most people did in the Windows Vista timeframe, by running a few RunSynchronous Commands in the specialize pass. I selected to use the AdministratorPassword/AutoLogon feature in my samples since I wanted to Autologon anyway.
Also, if you are deploying into a workgroup, like my samples, there is a need to specify an extra account in the unattend.xml, or the Windows 7 setup will stop and prompt youfor a user. In my sample I use a neat trick. Since I have enabled the administrator account, I simply specify that user as the extra account, and I avoid the need for creating an extra user which later may have to be deleted.
Regards / Johan Arwidmark
Chief Technical Architect – Knowledge Factory
Microsoft MVP - Setup / Deployment
Building a demo and lab environment is time consuming, but it doesn't need to
And in many cases really boring, but everything can be solved with a bit of “stuff”, the stuff we need this time is: WIM2VHD and PowerShell library for Hyper-V and some scripts. Download and install, and note that WIM2VHD needs WAIK tools.
• WIM2VHD - http://itbloggen.se/cs/blogs/micke/archive/2010/08/25/using-wim2vhd-to-create-reference-images-for-hyper-v.aspx
• PowerShell library for Hyper-V - http://pshyperv.codeplex.com/
So the only reason I have created these script is that we normally run the labs we have on non-activated licenses, I hate the fact that someone will give me a call in the future and say, -Hey, Mikey, you have provided a criminal network with software for 10 years for free, why?
Yes, there are other reasons to, but the concept is easy. I need to be able to rebuild servers, I need to be able to build things for testing and I need it fast and easy (or quick and dirty as the proper term is)
When you are done, you will be able to create a new VM, fire it up and logon in less than 2 minutes using this command
mvm.cmd E:\VM MIKE001 1024 LAN c:\Ref\W2K8r2x64.vhd
And that will build you a new machine that runs Windows Server 2008 R2 Enterprise x64, connected to LAN, called MIKE001 in E:\VM
Create the VHD file and here is a sample file for that:
cscript WIM2VHD.wsf /wim:"C:\MDTLab\Operating Systems\Windows Server 2008 R2 x64 RTM\sources\install.wim" /sku:SERVERENTERPRISE /unattend:"c:\tools\wim2vhd\Unattend - US.xml"
Now, “Unattend - US.xml” file is going to “fix” a lot of things, turn off OOBE, server Manager, IE Welcome, ESC and so on. Spend some time on that, I hate spending 15 minutes every time logging in to server the first time. I created that using WSIM but not from scratch, you can use MDT.
Create a PowerShell script that will be used as a template for creating new machines, and here is the sample file called bvm.ps1:
import-module "c:\Program Files\modules\HyperV\HyperV.psd1"
$VMLOC = $args
$VMNAME = $args
$VMMEM = $args
$VMNET = $args
$VMSRC = $args
$VM = New-VM -Name $VMNAME -Path $VMLOC
Set-VMCPUCount -VM $VM -CPUCount 1
Set-VMMemory -VM $VM -Memory $VMMEM
Add-VMNIC -VM $VM -VirtualSwitch $VMNET
Add-VMSCSIController -VM $VM -name "SCSI Controller"
$Disk1 = New-VHD -VHDPaths $VMLOC\$VMNAME-disk1.vhd -ParentVHDPath $VMSRC -Verbose -Wait
$Disk2 = New-VHD -VHDPaths $VMLOC\$VMNAME-disk2.vhd -Size 146gb -Verbose -Wait
Add-VMDisk -VM $VM -ControllerID 0 -LUN 0 -Path $Disk1
Add-VMDisk -VM $VM -ControllerID 0 -LUN 0 -Path $Disk2 -SCSI
Add-VMDisk -VM $VM -controllerID 1 -lun 1 "C:\MEDIA-TSLAB-LTI\LiteTouchMedia.iso" -DVD
Start-VM -VM $VM
No, the only thing that is left is the batch file (You could use the ps1 file as it is but then the command line will be a bit long, so I use cmd/bat files to make the command shorter and here is the sample file called mvm.cmd:
powershell -ExecutionPolicy RemoteSigned -file bvm.ps1 %1 %2 %3 %4 %5
Now you have a script that will build and start machines faster than you can use them, but hey, it’s fun J, if you like you can read the my blog post on this subject, that will give you some more information and tips.
Mikael Nystrom – TrueSec
MVP – Setup/Deployment
(PS, we are working on a book about server deployment, and this is one thing we will put in there)
Deploy Microsoft Office 2010 in a controlled manner
We need to deploy Microsoft Office 2010 to 12.000 computers during the same weekend (if possible) and keep network activity at a minimum during the deployment. The Office 2010 package must be downloaded to the client cache prior to the installation. The download must use BITS and the process should be completed at least 2 days before the actual deployment starts.
60% of all computers are laptops that are not always connected to the network. The remaining 40% are desktops which are all connected to the LAN.
1. Create a Microsoft Office 2010 package and distribute the package to all distribution points 3 weeks prior to the actual deployment. For information about how you create the Office 2010 package download the complete guide. The guide also explains how you create the Office MSP file and configure the deployment to install silently.
2. Make sure the package is deployed to all distribution points prior to creating any advertisement.
3. There is no feature in Configuration Manager 2007 that allows for a download to cache prior to installation. In order to force the download you need to manipulate with the advertisement. In my example I created a mandatory advertisement with a schedule in the future 20/4-2011. When the client sees this advertisement, it will automatically start the download.
4. To verify the download check:a. The canned report Status of a specific advertisementb. On the client you can check these log files:i. The CAS.log, it will give you valuable information about remaining space in the client cache size.
ii. LocationServices.log, it will give you information about which distribution point is used as a download source.
iii. Datatransferservice.log, it will give you all the BITS download information.
5. Once the software is downloaded you can modify the advertisement start time to the correct value.
a. The advertisement is configured with a start time at 03:00 AM.
b. Configure the R3 power management feature to power on all desktops at 03:00 AM. All desktops will start the installation at 03:00 AM and go back to sleep after the installation. Laptops will start the installation when they power on the computer after the mandatory deadline date. All installations will run from the local cache.
Med Venlig Hilsen / Best Regards
Kent Agerlund Senior Consultant, Coretech
Microsoft Configuration Manager MVP
The Marcus Murray signature way of Using Smartcards for
A common trend among my customers is that they want to start using smartcards for securing administrative account logons. The general idea is of course that they want to prevent various attacks that comes from using weak passwords. Examples are password brute-force attacks, man-in-the-middle attacks like password sniffing and cracking, sniffing of terminal-server logons etc.
Smart cards will effectively prevent these but there are other attacks that will not be prevented just by using smart-cards.
The most common and most dangerous attacks in this category are the passing-the-hash attacks and the passing-the dutchie attack.
Passing the hash is the concept of extracting the hash on one system and then use the hash to log on to another. A typical example is when a hacker obtains control over a client or a server where a Domain Admin-account is currently logged on, he extracts the hash and then uses it to authenticate to the domain controller as Domain Admin and compromise the entire domain.
Passing the dutchie is based on weaknesses in the ntlm network authentication, if a hacker can make an account connect to his system then he can pass the authentication forward to another system and impersonate the targeted account on that very system. This is of course very devastating if the attacker can make an admin connect to him.
The passing -the-hash-attack cannot be prevented by simply using smartcards because even if a user log on to a system using a smartcard, the hash will be generated in the context of the user session.
And the passing-the-dutchie attack will still be valid since ntlm authentication will still be used on the network (Unless you specifically restrict it using "Restrict NTLM-settings" or IPSEC)
A few weeks ago I was presenting a session at TechED Europe about Authentication and passwords in windows and I realized that there is a simple solution to both of these problems!
In windows Server 2008 R2 there is a new feature called "Authentication Mechanism Assurance" and it has been promoted by Microsoft as a way of creating controlled access to restricted data using different assurance levels.
The concept is a blueprint from the military approach where you have a certain level of trust and therefore can access a certain level of secret data.
The technology behind it is that you issue a special smart-card template and tie it together with a new "dynamic group".
Anyone who has a smart-card based on that template will temporarily become a member of the dynamic group when they logon using that smart card. Microsoft is only promoting this for requiring Smart card based authentication to access certain restricted data.
Thinking about this made me realize that this technology is perfect when it comes to implementing Smart cards for administrators.
As a simple yet effective example you can create 3 different smart-card templates based on different admin roles, one each for “Client Admins”, “Server Admins” & “Domain Admins”. You create them by simply duplication a regular Smart Card Template and create a unique issuance policy under the template extensions. (In the example below you can see a Smart Card template with a custom issuance policy named “TS Server Admins”).
After you created the different templates you create three corresponding universal groups.
And the final step is to tie each template together with the corresponding group.
The easiest tool for doing this is the Truesec Assurance Binder
A complete step-by-step to implement Authentication Mechanism Assurance is found here:
So. Why is using this technology for Smart Card based administration so great?
There are several benefits to this concept.
Let me give you some examples:
An admin can use the same account and profile for his everyday work without unnecessary exposure of high credentials. When he is only checking for emails etc. he can use a regular smartcard or even a password and he will not be a member of the Server Admins Group.
If he needs those privileges he simply does a runas or Terminal Server logon using the Smart Card containing the Server Admins issuance policy.
The biggest value here is the complete prevention of passing the hash attacks on administrative accounts.
Even if a hacker manages to steal the admins hash from a compromised system where he has recently logged on he can still not use it to get administrative access to other systems. Passing the hash without the smartcard will not put the server admins group sid in the hackers session. If the attacker tries to attack the account using a passing-the-dutchie attack then he will have the same issue. He can authenticate to a remote system but he cannot obtain the membership in the server admins group.
The overall result is that Authentication Mechanism Assurance is a simple way of killing a few of the most devastating attacks today without making live more difficult for the admins.
I really recommend that you consider this technique if you are thinking of implementing smart cards for your administrators. The only requirements is a Microsoft PKI and that you run the domain in Windows Server 2008 R2 Domain mode. When it comes to all the other servers and clients this technology is a 100% backward compatible, you can implement this even if you are still on XP or even Windows 2000. The only systems that needs an upgrade are the Domain Controllers.
If you have any questions regarding this you are welcome to contact me on my email marcus[at]Truesec[dot]com
Until then, stay safe!
Security Team Leader- Truesec
Where to find us
Come meet us at any of our labs. Below is a where we will hold labs during the next couple of months.
Coming Labs in the US
"Mastering MDT 2010 and WDS" with Mikael Nystrom Waltham November 29-December 1
"Deploying Windows 7 using MDT 2010 and SCCM 2007 SP2" with Johan Arwidmark, Waltham November 30 - December 2
"Mastering MDT 2010 and WDS" with Mikael Nystrom, Chicago 19-21, 2011
"Unleash the Power of MDT 2010 Lite Touch" with Mikael Nystrom Chicago January 22-23, 2011
"Deploying Windows 7 using MDT 2010 and SCCM 2007 SP2" with Johan Arwidmark, New York City January 19- 21, 2011
"Unleash the Power of MDT 2010 Lite Touch" with Johan Arwidmark New York City, January 22-23, 2011
"Mastering Windows Server 2008 R2" with Mikael Nystrom in Chicago January 24-26, 2011
"Mastering MDT 2010 and WDS" with Johan Arwidmark New York City, January 24-26, 2011
"Mastering SCCM 2007 SP2 R3" with Kent Agerlund, Chicago February 8-10, 2011