You may see a few posts on IPv6 through the summer. Keep tuned.
Sonicwall NSA firewall devices DO support IPv6. What they do not tell you is that you need a specific version of the firmware. (5.5.6) When you go to the downloads site, click on the previous versions link and look for the feature release - Version 5.5.6.0-IPv6.
Why they do not mention this anywhere is beyond me. But you've heard it here now. I hope my two days of frustrated hunting around will save you time.
Wednesday, 15 June 2011
Tuesday, 31 May 2011
SCCM, WinPE and 802.1x - Windows 7 Service Pack 1
In addition to my last post on this issue here, Windows 7 Service Pack 1 has brought with it only a minor change. The details in that post are still valid, with one minor exception.
In "Stage Two Prepare the WinPE Image" I referred to a hot fix package KB972831, which contained the WinPE module for 802.1x. This had to be added using DISM /add-package. Happily the Service Pack 1 AIK toolkit now contains the winpe-dot3svc.cab in the same location as the other three cabs (winpe-scripting.cab, winpe-wmi.cab, winpe-wds-tools.cab.)
This means that there is very little reconfiguration needed for introducing your SP1 image.
In "Stage Two Prepare the WinPE Image" I referred to a hot fix package KB972831, which contained the WinPE module for 802.1x. This had to be added using DISM /add-package. Happily the Service Pack 1 AIK toolkit now contains the winpe-dot3svc.cab in the same location as the other three cabs (winpe-scripting.cab, winpe-wmi.cab, winpe-wds-tools.cab.)
This means that there is very little reconfiguration needed for introducing your SP1 image.
SCCM and WDS
One of the most complained about problems on the SCCM technet message boards is when the PXE service point stops working. We have had this problem for some time now. The issue ranges from simply not starting after a reboot to not working at all after provisioning a new PXE service point. Our last PXE outage lasted about a month.
The problem is now that there are so many post on this issue, it is hard to find one with a workable solution. The first thing you should be aware of this blog from the Configuration Manager Support Team. This is the first place to go to when looking for solutions to your WDS and SCCM problems. As you will note, even they are constantly updating the information. The last update was on 6 January (or 1 June - depending how you read it) this year. The whole integration of SCCM and WDS is so complex, that even the people who created it are having a hard time.
And even after following the instructions in the above blog, you can still come up against a brick wall. For example: Simply uninstalling the SMS_PXE service point and the WDS server is not enough. You also need to delete the "remoteinstall" directory, or WDS will install and pick up the (probably wrong) settings when it is re-installed.
Another big issue is communications between the WDS server and the Database server. In the world of Windows Server 2008 R2, the firewall is switched on by default. Even with an SQL exception the WDS server can find itself blocked out of the Database. My solution there was to allow all traffic from the WDS server through to the SMS Database Server. My symptoms included the WDS services failing to load the SMS provider with 0x4005 error. As any persistent user of the Technet Forums knows, 0x4005 means 'access denied' in any application.
One of the best ways to figure out whether the issue is at the the WDS end or at the SCCM end, is to actually configure the WDS server as a WDS server. If you have already configured SCCM with a boot image and an OS image, it's really simple to do. After uninstalling and re-installing the WDS role, go ahead and configure the WDS server. Now before the server will start to server PXE, it needs a boot.wim and an install.wim. Having already configured the boot and OS images, you can simply pick them up from their source directories. Just pick up the boot.XXX0001A.wim files and drop them in a temporary directory on the WDS server. Rename the files boot.wim and install.wim. The fact that they are not configured for WDS use is neither here now there at this point. You just need to have both a boot and an install file in order for the WDS server to start servicing PXE requests. Using the WDS mmc console, add the boot file first, then add the install file. Now try to start the service and boot a client to PXE. If it works, your WDS installation is clean.
Following best practice, uninstall the WDS server as you did before, remembering to remove the remoteinstall directory, and then follow the instructions in the blog mentioned above. If you then have problems (even after setting a firewall exception for the WDS server on your SMS DB server) you are looking at a SCCM issue such as access by the WDS server's computer account to the database.
The problem is now that there are so many post on this issue, it is hard to find one with a workable solution. The first thing you should be aware of this blog from the Configuration Manager Support Team. This is the first place to go to when looking for solutions to your WDS and SCCM problems. As you will note, even they are constantly updating the information. The last update was on 6 January (or 1 June - depending how you read it) this year. The whole integration of SCCM and WDS is so complex, that even the people who created it are having a hard time.
And even after following the instructions in the above blog, you can still come up against a brick wall. For example: Simply uninstalling the SMS_PXE service point and the WDS server is not enough. You also need to delete the "remoteinstall" directory, or WDS will install and pick up the (probably wrong) settings when it is re-installed.
Another big issue is communications between the WDS server and the Database server. In the world of Windows Server 2008 R2, the firewall is switched on by default. Even with an SQL exception the WDS server can find itself blocked out of the Database. My solution there was to allow all traffic from the WDS server through to the SMS Database Server. My symptoms included the WDS services failing to load the SMS provider with 0x4005 error. As any persistent user of the Technet Forums knows, 0x4005 means 'access denied' in any application.
One of the best ways to figure out whether the issue is at the the WDS end or at the SCCM end, is to actually configure the WDS server as a WDS server. If you have already configured SCCM with a boot image and an OS image, it's really simple to do. After uninstalling and re-installing the WDS role, go ahead and configure the WDS server. Now before the server will start to server PXE, it needs a boot.wim and an install.wim. Having already configured the boot and OS images, you can simply pick them up from their source directories. Just pick up the boot.XXX0001A.wim files and drop them in a temporary directory on the WDS server. Rename the files boot.wim and install.wim. The fact that they are not configured for WDS use is neither here now there at this point. You just need to have both a boot and an install file in order for the WDS server to start servicing PXE requests. Using the WDS mmc console, add the boot file first, then add the install file. Now try to start the service and boot a client to PXE. If it works, your WDS installation is clean.
Following best practice, uninstall the WDS server as you did before, remembering to remove the remoteinstall directory, and then follow the instructions in the blog mentioned above. If you then have problems (even after setting a firewall exception for the WDS server on your SMS DB server) you are looking at a SCCM issue such as access by the WDS server's computer account to the database.
Thursday, 21 April 2011
Disable MS Word 2007 Proofing Tools via Group Policy
Yes it is possible!
Why would I want to do this? Well, for exams, of course. In order to have multi-use PCs that are used for teaching to have the possiblity of use for qualified exams, the PCs need to have it's proofing tools tied down.
The other things like internet access and access to network locations is easy enough, but how do you lock down Proofing in Word 2007? Well, you have probably at first glance seen the Group Policy Objects for Word 2007. You can find them in User Settings/Administrative Templates/Microsoft Office Word 2007/Word Options/Proofing. But, as anyone who has ever tried these settings knows, when you open Word 2007, the settings are easily switched back on or bybassed by using the items in the proofing toolbar or by going into the options.
Ah - but what if you could disable the specific user interface items? Well you can - that's easy: Under Microsoft Office Word 2007/Disable Items in User Interface/Custom you can do this. Microsoft has a whole page devoted to this subject. You can find that here.
So what IDs do you disable. Well here is my list:
2566
15780
9056
6111
12842
14453
2815
3492
3492
4025
3997
3958
790
2
3217
2349
329
3219
2469
2788
11323
7343
7387
The important one, the one that is not in the documentation, is 11323. including this ID disables the "Options" button in the Office Button (that un-named circle that someone sensible renamed 'File' in Office 2010.) Without the "options" button disabled, those pesky office group policies can be over-ridden by the user. Without access to options, the user must accept a proofless Word.
But that is not quite enough. It is still possible to gain access to Options by using the "Alt-T, O" legacy key press. But once again, there is an answer. In the same folder as 'Disable commands,' is 'Disable shortcut keys.'
Once again here is my list:
118
254
79,12
118,16
118,4
The 254 entry is equivalent to the key and option combination 84,16. It's not that clearly explained, the key is the standard ascii character that is being used in the combination. 84 is t. The number following the comma is the option. Alt is 16, Ctrl is 8 and Shift is 4. Any combination adds up; so Ctrl-Shift is 12 (8 + 4).
So these options will now disable:
So now we have used the standard group policies to disable proofing on Word 2007. The User interface buttons are disabled and the options menu is also unreachable so that the disabled options can no longer be turned back on.
The only thing left to do is to make sure the Group Policy Object is targeted only at your Exam login, or your teachers are going to get very angry with you.
Why would I want to do this? Well, for exams, of course. In order to have multi-use PCs that are used for teaching to have the possiblity of use for qualified exams, the PCs need to have it's proofing tools tied down.
The other things like internet access and access to network locations is easy enough, but how do you lock down Proofing in Word 2007? Well, you have probably at first glance seen the Group Policy Objects for Word 2007. You can find them in User Settings/Administrative Templates/Microsoft Office Word 2007/Word Options/Proofing. But, as anyone who has ever tried these settings knows, when you open Word 2007, the settings are easily switched back on or bybassed by using the items in the proofing toolbar or by going into the options.
Ah - but what if you could disable the specific user interface items? Well you can - that's easy: Under Microsoft Office Word 2007/Disable Items in User Interface/Custom you can do this. Microsoft has a whole page devoted to this subject. You can find that here.
So what IDs do you disable. Well here is my list:
2566
15780
9056
6111
12842
14453
2815
3492
3492
4025
3997
3958
790
2
3217
2349
329
3219
2469
2788
11323
7343
7387
The important one, the one that is not in the documentation, is 11323. including this ID disables the "Options" button in the Office Button (that un-named circle that someone sensible renamed 'File' in Office 2010.) Without the "options" button disabled, those pesky office group policies can be over-ridden by the user. Without access to options, the user must accept a proofless Word.
But that is not quite enough. It is still possible to gain access to Options by using the "Alt-T, O" legacy key press. But once again, there is an answer. In the same folder as 'Disable commands,' is 'Disable shortcut keys.'
Once again here is my list:
118
254
79,12
118,16
118,4
The 254 entry is equivalent to the key and option combination 84,16. It's not that clearly explained, the key is the standard ascii character that is being used in the combination. 84 is t. The number following the comma is the option. Alt is 16, Ctrl is 8 and Shift is 4. Any combination adds up; so Ctrl-Shift is 12 (8 + 4).
So these options will now disable:
- 118 - F7 Do a spell check
- 79,12 - Ctrl-Shift-o - Opens the research bar
- 254 (or 84,16) - Alt-T Legacy Tools Menu
So now we have used the standard group policies to disable proofing on Word 2007. The User interface buttons are disabled and the options menu is also unreachable so that the disabled options can no longer be turned back on.
The only thing left to do is to make sure the Group Policy Object is targeted only at your Exam login, or your teachers are going to get very angry with you.
Thursday, 21 October 2010
Integrating a Cisco CUCM 7.x cluster with multiple Exchange 2010 UM servers
Microsoft's Exchange 2010 Unified Messaging is shaping up to be a top class messaging system. Cisco's Unified Call Manager is a steady standard for VOIP. Can the two live together in a high availability environment? yes they can, and here is how.
CUCM's cluster exists as a failover solution. If the Primary Server fails, devices contact the secondary (or tertiary) server. Changes made on the Primary are replicated to the Secondary. Exchange 2010 allows for as many UM servers as your organisation needs. Failed calls to one server are re-routed to another. Once there are two UM servers it also load balances between the two. Having a Call Manager and a Unified Messaging Server in each of your DR sites effectively means uninterrupted access to voicemail, auto attendants, etc.
Note that we had Cisco Unity enabled and running throughout the time we migrated to UM and they happily sat side by side.
Starting with Exchange UM: We will assume that you have created your Dial Plan and Mailbox Policies and skip straight to creating a new IP Gateway. Specify the name (being possibly the name of the Primary CUCM Server) and specify the IPv4 address. After creating the IP Gateway, right click the gateway and select Properties. Make sure "Allow outgoing calls through this UM IP Gateway" and "Allow Message Waiting Indicator" are both ticked. Create a new IP Gateway for the Secondary CUCM Server with the same details enabled.
Now for the CUCM set up. You may be told that some of these steps are unnecessary, especially in regard to Media Resource Groups. We listened to experience of other users where not using Media Resource Groups caused a problem. In the end, following this path did not result in any problems.
You should already have Media Termination Points set up, one for each server, although only one may be active on the secondary server. You can view them by going to Media Resources -> Media Termination Points. Note their names. Create a Media Resource Group under Media Resources -> Media Resource Group (We'll call it MRG_CCM) and add the previously noted Media Termination Points. Now create a Media Resource Group List (we'll call this MRGL_CCM) that contains the Media Resource Group MRG_CCM.
Go to System -> Device Pool. Copy the Default pool and call it Ex_UM_Device_Pool. In Ex_UM_Device_Pool specify the MRGL_CCM Media Resource Group List and save. (Why this step I don't know, the following steps don't use this profile?!!)
Go to System -> Security Profile -> SIP Trunk Profile. Copy the existing Non Secure SIP Trunk Profile and call it e12_NS_SIP_Trunk_Profile. Tick the boxes for "Accept Out-Of-Dialog REFER", "Accept Unsolicited Notification" and "Accept Replaces Header". Leave the other settings untouched.
Go to Device -> Trunk and create a new trunk with Trunk Type being "SIP Trunk" and Device Protocol being "SIP". Under "Device Information" change the Media Resource Group List to MRGL_CCM. Tick "Media Termination Point Required." Under Call Routing Information select your internal Calling Search Space and tick "Redirecting Diversion Header Delivery - Inbound." (The calling search space is needed for the 'Listen on Phone' feature. Change Calling Party Selection to "Originator" and tick "Redirecting Diversion Header Delivery - Outbound." Under SIP Information enter the IP Address of your first Exchange Unified Messaging server. For SIP trunk Security Profile, select the previously created e12_NS_SIP_Trunk_Profile. Set the Rerouting Calling Search Space to Internal. Finally for SIP Profile select the Standard SIP Profile.
Note that the Standard SIP Profile must have a Default MTP Telephony Event Payload Type of 101. If it is different, you will need to create a new SIP profile and use it here.
Create a new Trunk for each additional UM Server using the above information. (You can test these trunks by adding a route directly into the trunks themselves. However, you will need to remove all routes to those trunks before you add the trunk into a route group. You cannot have the trunk individually routed to AND in a route trunk. If you need to route to an individual Trunk for a specific reason, you can create a separate Route Group List, etc.)
Now to create a Route Group that contains all of the Trunks you have created to the Unified Messaging servers. Under Call Routing -> Route/Hunt -> Route Group select Add New. We will call this e12_UM_Route_Group. Highlight the Trunks you have created. They will only appear here if you have not specified them in a Route Pattern already. Click on Add to Route Group to include them.
Now Create a Route List that can be used in a Route Patter by going to Call Routing -> Route/Hunt -> Route Group. We will call it e12_UM_Route_List. Add the previously created e12_UM_Route_Group.
Now to create a Route Pattern. Under Call Routing -> Route/Hunt -> Route Pattern select Add New. Enter the voicemail access number (We will pretend this is 2010) leave the Route Partition blank. Select the previously created e12_UM_Route_List under Gateway/Route List and make sure "Route this pattern" is selected. Make sure that under the section "Calling Party Transformations" the calling Line ID Presentation is set to "Allowed."
Under Voice Mail -> Voice Mail Pilot, select Add New. Enter 2010 for "Voice Mail Pilot Number" and leave the Calling Search Space as.
Under Voice Mail -> Voice Mail Profile, select Add New. We will give it the name UM2010_Profile. Select the newly created Pilot 2010/.
Back in Exchange -> Organisation Configuration -> Unified Message (UM Dial Plans tab) Open the properties of your dial plan and select Subscriber Access. Ensure to associate the Voice Mail Pilot number (ours is 2010 in this example) with the dial plan.
Find a suitable test mailbox that you have full access to under recipient configuration -> Mailbox. Select "Enable Unified Messaging" and assign a suitable extension, we will select 1050 for example.
Back to CUCM under Call Routing -> Directory Number. Find your extension test extension 1050. Under Voice Mail Profile select UM2010_Profile. Make sure that Call Forward Settings allow forwarding to voicemail.
You should now be able to access Exchange Voicemail from that phone by pressing the messages button, and be able to call into the system. This setup should now be secure from a power failure at either DR site.
CUCM's cluster exists as a failover solution. If the Primary Server fails, devices contact the secondary (or tertiary) server. Changes made on the Primary are replicated to the Secondary. Exchange 2010 allows for as many UM servers as your organisation needs. Failed calls to one server are re-routed to another. Once there are two UM servers it also load balances between the two. Having a Call Manager and a Unified Messaging Server in each of your DR sites effectively means uninterrupted access to voicemail, auto attendants, etc.
Note that we had Cisco Unity enabled and running throughout the time we migrated to UM and they happily sat side by side.
Starting with Exchange UM: We will assume that you have created your Dial Plan and Mailbox Policies and skip straight to creating a new IP Gateway. Specify the name (being possibly the name of the Primary CUCM Server) and specify the IPv4 address. After creating the IP Gateway, right click the gateway and select Properties. Make sure "Allow outgoing calls through this UM IP Gateway" and "Allow Message Waiting Indicator" are both ticked. Create a new IP Gateway for the Secondary CUCM Server with the same details enabled.
Now for the CUCM set up. You may be told that some of these steps are unnecessary, especially in regard to Media Resource Groups. We listened to experience of other users where not using Media Resource Groups caused a problem. In the end, following this path did not result in any problems.
You should already have Media Termination Points set up, one for each server, although only one may be active on the secondary server. You can view them by going to Media Resources -> Media Termination Points. Note their names. Create a Media Resource Group under Media Resources -> Media Resource Group (We'll call it MRG_CCM) and add the previously noted Media Termination Points. Now create a Media Resource Group List (we'll call this MRGL_CCM) that contains the Media Resource Group MRG_CCM.
Go to System -> Device Pool. Copy the Default pool and call it Ex_UM_Device_Pool. In Ex_UM_Device_Pool specify the MRGL_CCM Media Resource Group List and save. (Why this step I don't know, the following steps don't use this profile?!!)
Go to System -> Security Profile -> SIP Trunk Profile. Copy the existing Non Secure SIP Trunk Profile and call it e12_NS_SIP_Trunk_Profile. Tick the boxes for "Accept Out-Of-Dialog REFER", "Accept Unsolicited Notification" and "Accept Replaces Header". Leave the other settings untouched.
Go to Device -> Trunk and create a new trunk with Trunk Type being "SIP Trunk" and Device Protocol being "SIP". Under "Device Information" change the Media Resource Group List to MRGL_CCM. Tick "Media Termination Point Required." Under Call Routing Information select your internal Calling Search Space and tick "Redirecting Diversion Header Delivery - Inbound." (The calling search space is needed for the 'Listen on Phone' feature. Change Calling Party Selection to "Originator" and tick "Redirecting Diversion Header Delivery - Outbound." Under SIP Information enter the IP Address of your first Exchange Unified Messaging server. For SIP trunk Security Profile, select the previously created e12_NS_SIP_Trunk_Profile. Set the Rerouting Calling Search Space to Internal. Finally for SIP Profile select the Standard SIP Profile.
Note that the Standard SIP Profile must have a Default MTP Telephony Event Payload Type of 101. If it is different, you will need to create a new SIP profile and use it here.
Create a new Trunk for each additional UM Server using the above information. (You can test these trunks by adding a route directly into the trunks themselves. However, you will need to remove all routes to those trunks before you add the trunk into a route group. You cannot have the trunk individually routed to AND in a route trunk. If you need to route to an individual Trunk for a specific reason, you can create a separate Route Group List, etc.)
Now to create a Route Group that contains all of the Trunks you have created to the Unified Messaging servers. Under Call Routing -> Route/Hunt -> Route Group select Add New. We will call this e12_UM_Route_Group. Highlight the Trunks you have created. They will only appear here if you have not specified them in a Route Pattern already. Click on Add to Route Group to include them.
Now Create a Route List that can be used in a Route Patter by going to Call Routing -> Route/Hunt -> Route Group. We will call it e12_UM_Route_List. Add the previously created e12_UM_Route_Group.
Now to create a Route Pattern. Under Call Routing -> Route/Hunt -> Route Pattern select Add New. Enter the voicemail access number (We will pretend this is 2010) leave the Route Partition blank. Select the previously created e12_UM_Route_List under Gateway/Route List and make sure "Route this pattern" is selected. Make sure that under the section "Calling Party Transformations" the calling Line ID Presentation is set to "Allowed."
Under Voice Mail -> Voice Mail Pilot, select Add New. Enter 2010 for "Voice Mail Pilot Number" and leave the Calling Search Space as
Under Voice Mail -> Voice Mail Profile, select Add New. We will give it the name UM2010_Profile. Select the newly created Pilot 2010/
Back in Exchange -> Organisation Configuration -> Unified Message (UM Dial Plans tab) Open the properties of your dial plan and select Subscriber Access. Ensure to associate the Voice Mail Pilot number (ours is 2010 in this example) with the dial plan.
Find a suitable test mailbox that you have full access to under recipient configuration -> Mailbox. Select "Enable Unified Messaging" and assign a suitable extension, we will select 1050 for example.
Back to CUCM under Call Routing -> Directory Number. Find your extension test extension 1050. Under Voice Mail Profile select UM2010_Profile. Make sure that Call Forward Settings allow forwarding to voicemail.
You should now be able to access Exchange Voicemail from that phone by pressing the messages button, and be able to call into the system. This setup should now be secure from a power failure at either DR site.
Monday, 21 June 2010
SCCM, WinPE and 802.1x - The Director's Cut
I've been busy. After many months of asking questions I seem to have come up with a definitive 'working in all scenarios' guide to enabling 802.1x in WinPE and working with System Center Configuration Manager. It seems my previous post on this was a little premature but provided a testing a ground for the technology.
So the problems that occurred following my last post were:
I explained in my last post why certain files are needed, so please read this as I will shorten this post by not rewriting this information.
So here goes:
Stage 1 Prepare the files for WinPE
You will need to prepare two xml files (see This Technet Post for the XML content) for authentication purposes. I shall call them profile.xml for the LAN Profile and uprofile.xml for the EAP Host User Credentials.
Prepare a file called TSConfig.ini that contains:
[CustomHook]
CommandLine="x:\Windows\system32\cscript.exe x:\windows\System32\8021x.vbs"
Prepare a file called 8021x.vbs that contains:
Set objshell = CreateObject("Wscript.Shell")
Q = chr(34)
objshell.Run "%comspec% /c net start dot3svc", 0, True
objshell.Run "%comspec% /c netsh lan set autoconfig enabled=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%compsec% /c netsh lan add profile filename=%systemdrive%\windows\system32\profile.xml interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan set eapuserdata filename = %systemdrive%\windows\system32\uprofile.xml allusers=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan reconnect interface =" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q", 0, True
...
I have added additional script after this point to detect encrypted drives and ask the user to format it. There is a good reason for this. You are about to create a custom WinPE image. If the image is over 100Mb, and you have already used bitlocker on your machines, then the usual size of the boot partition is just 100Mb. If there is a need to download the image to the PC (as happens when you switch architectures or initiate the rebuild from Control Panel) the sequence fails because of insufficient space. But you can add any other scripts in at this point for your own purposes and they will run before the Task Sequence starts.
Stage 2 Prepare the WinPE Image
Mount a vanilla WinPE image using DISM and add the packages in order (or they will fail):
Commit the image and present this as the source for the boot image in the Configuration Manager Console. Now you can update the Image and it will work in all modes. The tsconfig.ini contains a hook that will be executed before any task sequence begins. Note, that this runs before the policy is checked, but after any task media password.
Stage 3 Prepare the Windows images
Windows also needs to authenticate in the first stages of installation or the build will fail. So all of the following needs to be done in Windows before you capture your reference image for SCCM:
Stage 4 Amend the custom settings
If you followed the MS guidelines when adding the MDT2010 to SCCM, you will have task sequences that refer to a Custom Settings Package. Locate the source files for this package and amend the Unattend.xml
Locate the section "Mircosoft-Windows-Deployment" and note that there are 3 commands undersub section. Add a 4 as follows:
<runsynchronouscommand action="add">
<description>Configure 802.1x</description>
<order>4</order>
<path>cscript.exe c:\windows\system32\8021x.vbs</path>
</runsynchronouscommand>
The way it works:
Booting to PXE downloads the image, before the task sequence runs it looks for a file called TSConfig.xml in the root of the WinPE image. It then executes any commandline entries it finds in the CustomHook section. This runs the scripts necessary to initiate an 802.1x connection with a user name and password in the profile.xml and uprofile.xml files. (We set up an account for connection that can be enabled as and when we decide to rebuild our PCs.)
If the architecture needs changing, the appropriate WinPE image is now downloaded (without HASH issues) and booted from, once again initiating the 802.1x from the scripts in CustomHook.
Once the image is applied and Windows Boots for the first time, the RunSynchronous Command is run before any other commands are run and 802.1x is established. After joining the domain, group policy takes over and the Computer is instructed to authenticate using its computer account.
And that is about it
This effectively adds all the components needed for a successful connection and build that will work without being the ugly hack it was before.
So the problems that occurred following my last post were:
- The 802.1x only occurred only at initial boot and subsequent reboots failed to authenticate. This was because the TSBootshell.ini file was only run when initially running the task sequence and not when continuing a task sequence.
- Changing the WIM file after updating the package resulted a package hash mismatch (as the hash is calculated when SCCM updates the package, not when the DPs are refreshed.) This meant that the image could only be used for initial boot and failed when the image was downloaded (either from within Windows or when switching architecture.)
I explained in my last post why certain files are needed, so please read this as I will shorten this post by not rewriting this information.
So here goes:
Stage 1 Prepare the files for WinPE
You will need to prepare two xml files (see This Technet Post for the XML content) for authentication purposes. I shall call them profile.xml for the LAN Profile and uprofile.xml for the EAP Host User Credentials.
Prepare a file called TSConfig.ini that contains:
[CustomHook]
CommandLine="x:\Windows\system32\cscript.exe x:\windows\System32\8021x.vbs"
Prepare a file called 8021x.vbs that contains:
Set objshell = CreateObject("Wscript.Shell")
Q = chr(34)
objshell.Run "%comspec% /c net start dot3svc", 0, True
objshell.Run "%comspec% /c netsh lan set autoconfig enabled=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%compsec% /c netsh lan add profile filename=%systemdrive%\windows\system32\profile.xml interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan set eapuserdata filename = %systemdrive%\windows\system32\uprofile.xml allusers=yes interface=" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c netsh lan reconnect interface =" & Q & "Local Area Connection" & Q, 0, True
objshell.Run "%comspec% /c del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q", 0, True
...
I have added additional script after this point to detect encrypted drives and ask the user to format it. There is a good reason for this. You are about to create a custom WinPE image. If the image is over 100Mb, and you have already used bitlocker on your machines, then the usual size of the boot partition is just 100Mb. If there is a need to download the image to the PC (as happens when you switch architectures or initiate the rebuild from Control Panel) the sequence fails because of insufficient space. But you can add any other scripts in at this point for your own purposes and they will run before the Task Sequence starts.
Stage 2 Prepare the WinPE Image
Mount a vanilla WinPE image using DISM and add the packages in order (or they will fail):
- winpe-scripting.cab
- winpe-wmi.cab
- winpe-wds-tools.cab
- windows6.1-KB972831-x86.MSU (or the x64 for the 64bit WinPE...)
Commit the image and present this as the source for the boot image in the Configuration Manager Console. Now you can update the Image and it will work in all modes. The tsconfig.ini contains a hook that will be executed before any task sequence begins. Note, that this runs before the policy is checked, but after any task media password.
Stage 3 Prepare the Windows images
Windows also needs to authenticate in the first stages of installation or the build will fail. So all of the following needs to be done in Windows before you capture your reference image for SCCM:
- Set the dot3svc (Wired Autoconfig) Service to Automatic
- Copy the profile.xml, uprofile.xml and 8021x.vbs files (as above) to Windows\System32
- Install the Windows 7 hotfix KB976210
Stage 4 Amend the custom settings
If you followed the MS guidelines when adding the MDT2010 to SCCM, you will have task sequences that refer to a Custom Settings Package. Locate the source files for this package and amend the Unattend.xml
Locate the section "Mircosoft-Windows-Deployment" and note that there are 3 commands under
<runsynchronouscommand action="add">
<description>Configure 802.1x</description>
<order>4</order>
<path>cscript.exe c:\windows\system32\8021x.vbs</path>
</runsynchronouscommand>
The way it works:
Booting to PXE downloads the image, before the task sequence runs it looks for a file called TSConfig.xml in the root of the WinPE image. It then executes any commandline entries it finds in the CustomHook section. This runs the scripts necessary to initiate an 802.1x connection with a user name and password in the profile.xml and uprofile.xml files. (We set up an account for connection that can be enabled as and when we decide to rebuild our PCs.)
If the architecture needs changing, the appropriate WinPE image is now downloaded (without HASH issues) and booted from, once again initiating the 802.1x from the scripts in CustomHook.
Once the image is applied and Windows Boots for the first time, the RunSynchronous Command is run before any other commands are run and 802.1x is established. After joining the domain, group policy takes over and the Computer is instructed to authenticate using its computer account.
And that is about it
This effectively adds all the components needed for a successful connection and build that will work without being the ugly hack it was before.
Friday, 19 February 2010
SCCM, WinPE and 802.1x
Running deployment tasks from SCCM on a network with 802.1x security is now possible, thanks to an update from Microsoft. It is a shame that we seem to have been left with an Ikea table set with all the parts but no instructions. So here is a first run "How to enable 802.1x on your SCCM" implentation. This example uses MS-PEAP without certificates.
First off, I will not explain how to set up a 802.1x on your network. Sufficient enouogh it is to say that you need to have an authentication rule that identifies a group with a single domain user specifically for network connectivity alone. This is so that when your winPE 802.1x client passes the username and password, it is authorised and passed a vlan for the installation to run on. I would strongly suggest that this account has no other privilege. For comparison, our test bed is running on Cisco 3560 switches, with a Windows Server 2008 Network Policy Server standing in for RADIUS. We are running SCCM 2007 SP2. We use MDT 2010 which includes winPE 3.0.
The first thing to do is add the KB972831 Hotfix to winPE. I choose to forgive Microsoft for writing in their documentation for this fix (and I quote) "Install and run" and "There are no prerequisites" both of which are most unhelpful. There are two ways to add the hotfix. Before importing the boot image, and SCCM builds the image. You are going to have to amend the boot image after it is built and before it is distributed to the distribution points anyway, so I have taken the second option.
If you want to add the hotfix to a clean winPE image, then before adding the hotfix, add the winPE components for Scripting, WDS Tools and WMI. SCCM does this anyway when it prepares an image. My best guess is that one of these is an unwritten prerequisite to the hotfix.
After updating the boot image with the required drivers, you can find the BOOT.XXX99999.WIM file under \Program Files\Microsoft Configuration Manager\OSD\boot\i386. Copy this to your MDT (Microsoft Deployment Toolkit) prepared workstation. Make sure you have an empty mount directory first. Run your department tools command prompt and then run:
C:\>imagex /mountrw boot.xxx99999.wim 1 c:\mount
C:\>dism /image:c:\mount /add-package /packagepath:c:\temp\Windows6.1-KB972831-x86.MSU
C:\>dism /image:c:\mount .get-packages
(Needless to say that you need to match architectures - No egg sucking lessons here...) Get-Packages confirms that the package is indeed added.
Before committing the image, we need to make a few more changes. The DOT3SVC (Wired Autoconfiguration) does not start automatically, so we need to find a way to kick it off before the task sequence runs. This is an ugly hack, so I hope you do not mind. I am sure the next release of SCCM will have this sorted natively...
We are going to create 3 files and amend another one already in the image. The first is profile.xml - a LANProfile for the Local Area Connection interface. This contains the settings for the interface. (Thanks to Andrew Husking for this version.) You can create your own be going to any Windows 7 interface and exporting the configuration using netsh if you wish. This one works fine.
The second file is uprofile.xml. This file contains the user credentials (EapHostUserCredentials) needed to log into the network. Remember that I said you want an account that has no other purpose, this is because this account will be included in this plain text file and sent to the pxe client. (Once again thanks to Andrew Husking.) Just change the usename and password.
You can find the xml for these two files on this technet board here... (Note that I left the RoutingIdentity as 'test' and it did no harm.
Place these two files in c:\mount\windows\system32
The third file is a batch file pretsmboot.cmd. This contains the following:
@echo off
net start dot3svc
netsh lan set autoconfig enable=yes interface="Local Area Connection"
netsh lan add profile filename=%SYSTEMDRIVE%\windows\system32\profile.xml interface="Local Area Connection"
netsh lan set eapuserdata filename=%SYSTEMDRIVE%\windows\system32\uprofile.xml interface="Local Area Connection"
netsh lan reconnect interface="Local Area Connection"
del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q
x:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%
Copy this file to c:\mount\sms\bin\i386
Finally, copy the file TsBootShell.ini out from c:\mount\sms\bin\i386 to Documents. Edit it so that the last line reads:
Run=x:\sms\bin\i386\pretsmboot.cmd
You will notice that the last thing pretsmboot.cmd does is kick off the line that you have just replaced. Copy the tsBootShell.ini back to c:\mount\sms\bin\i386
Now you can commit the changes back to the wim using:
C:\>imagex /unmount /commit c:\mount
(It is possible to do the image mounting and dismounting with DISM but I find imagex more mature and cleaner.) Copy the boot.xxx99999.wim file back to its original location on your SCCM server. Go into the Configuration Manager Console and go back to Boot Images. Right click your boot image and select Manage Distribution Points to start the wizard off. Choose Refresh the package on selected distribution points. If you select Update anywhere in this process, you will overwrite the image you have just made changes to.
There are consequences to this. The biggest and most obvious is that you cannot allow your boot image to automatically rebuild and update (obviously) because you need to inject the scripts and profile before refreshing the distribution points. The update of files can easily be scripted into a batch file but needs to be manually monitored as the MSU update can fail???
Another consequence is that you lose to ability to build on insecure ports. This new image you have created is 802.1x only. You will need to create another boot image without the amendments.
The final consequence I want to mention is the ugly dos screen this hack brings up. Yes, I could probably write a vbs that does the same thing without the dos window. I might just do that, but I am running out of half term...
So there you are - one working 802.1x winPE implementation using SCCM.
First off, I will not explain how to set up a 802.1x on your network. Sufficient enouogh it is to say that you need to have an authentication rule that identifies a group with a single domain user specifically for network connectivity alone. This is so that when your winPE 802.1x client passes the username and password, it is authorised and passed a vlan for the installation to run on. I would strongly suggest that this account has no other privilege. For comparison, our test bed is running on Cisco 3560 switches, with a Windows Server 2008 Network Policy Server standing in for RADIUS. We are running SCCM 2007 SP2. We use MDT 2010 which includes winPE 3.0.
The first thing to do is add the KB972831 Hotfix to winPE. I choose to forgive Microsoft for writing in their documentation for this fix (and I quote) "Install and run" and "There are no prerequisites" both of which are most unhelpful. There are two ways to add the hotfix. Before importing the boot image, and SCCM builds the image. You are going to have to amend the boot image after it is built and before it is distributed to the distribution points anyway, so I have taken the second option.
If you want to add the hotfix to a clean winPE image, then before adding the hotfix, add the winPE components for Scripting, WDS Tools and WMI. SCCM does this anyway when it prepares an image. My best guess is that one of these is an unwritten prerequisite to the hotfix.
After updating the boot image with the required drivers, you can find the BOOT.XXX99999.WIM file under \Program Files\Microsoft Configuration Manager\OSD\boot\i386. Copy this to your MDT (Microsoft Deployment Toolkit) prepared workstation. Make sure you have an empty mount directory first. Run your department tools command prompt and then run:
C:\>imagex /mountrw boot.xxx99999.wim 1 c:\mount
C:\>dism /image:c:\mount /add-package /packagepath:c:\temp\Windows6.1-KB972831-x86.MSU
C:\>dism /image:c:\mount .get-packages
(Needless to say that you need to match architectures - No egg sucking lessons here...) Get-Packages confirms that the package is indeed added.
Before committing the image, we need to make a few more changes. The DOT3SVC (Wired Autoconfiguration) does not start automatically, so we need to find a way to kick it off before the task sequence runs. This is an ugly hack, so I hope you do not mind. I am sure the next release of SCCM will have this sorted natively...
We are going to create 3 files and amend another one already in the image. The first is profile.xml - a LANProfile for the Local Area Connection interface. This contains the settings for the interface. (Thanks to Andrew Husking for this version.) You can create your own be going to any Windows 7 interface and exporting the configuration using netsh if you wish. This one works fine.
The second file is uprofile.xml. This file contains the user credentials (EapHostUserCredentials) needed to log into the network. Remember that I said you want an account that has no other purpose, this is because this account will be included in this plain text file and sent to the pxe client. (Once again thanks to Andrew Husking.) Just change the usename and password.
You can find the xml for these two files on this technet board here... (Note that I left the RoutingIdentity as 'test' and it did no harm.
Place these two files in c:\mount\windows\system32
The third file is a batch file pretsmboot.cmd. This contains the following:
@echo off
net start dot3svc
netsh lan set autoconfig enable=yes interface="Local Area Connection"
netsh lan add profile filename=%SYSTEMDRIVE%\windows\system32\profile.xml interface="Local Area Connection"
netsh lan set eapuserdata filename=%SYSTEMDRIVE%\windows\system32\uprofile.xml interface="Local Area Connection"
netsh lan reconnect interface="Local Area Connection"
del %SYSTEMDRIVE%\windows\system32\uprofile.xml /Q
x:\sms\bin\i386\TsmBootstrap.exe /env:WinPE /configpath:%CONFIGPATH%
Copy this file to c:\mount\sms\bin\i386
Finally, copy the file TsBootShell.ini out from c:\mount\sms\bin\i386 to Documents. Edit it so that the last line reads:
Run=x:\sms\bin\i386\pretsmboot.cmd
You will notice that the last thing pretsmboot.cmd does is kick off the line that you have just replaced. Copy the tsBootShell.ini back to c:\mount\sms\bin\i386
Now you can commit the changes back to the wim using:
C:\>imagex /unmount /commit c:\mount
(It is possible to do the image mounting and dismounting with DISM but I find imagex more mature and cleaner.) Copy the boot.xxx99999.wim file back to its original location on your SCCM server. Go into the Configuration Manager Console and go back to Boot Images. Right click your boot image and select Manage Distribution Points to start the wizard off. Choose Refresh the package on selected distribution points. If you select Update anywhere in this process, you will overwrite the image you have just made changes to.
There are consequences to this. The biggest and most obvious is that you cannot allow your boot image to automatically rebuild and update (obviously) because you need to inject the scripts and profile before refreshing the distribution points. The update of files can easily be scripted into a batch file but needs to be manually monitored as the MSU update can fail???
Another consequence is that you lose to ability to build on insecure ports. This new image you have created is 802.1x only. You will need to create another boot image without the amendments.
The final consequence I want to mention is the ugly dos screen this hack brings up. Yes, I could probably write a vbs that does the same thing without the dos window. I might just do that, but I am running out of half term...
So there you are - one working 802.1x winPE implementation using SCCM.
Subscribe to:
Posts (Atom)
