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.

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:

• 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.)

While 802.1x worked, there were obvious flaws. But with a bit more poking at the TechNet forums I managed to over come these. So this post is not all my own knowledge and work, there are other people in the background proving each point.

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...)

Copy TSConfig.ini to the root of the mounted image. Copy the other 3 files to the Windows\System32 directory in the mounted image.

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

After these are done, you can then capture an image for use with 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 under sub 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.

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.

What to do with an iPad

Okay, let's think about it. What would make the iPad something I would want? The device has just been released. It is smooth, responsive, powerful and portable. Whatever you might think of Apple, this is the device that is closest to what you see envisioned in sci-fi. The pad device.

But with the missing feature list as long as my arm, what would I need it for? The answer is clearly for me, nothing! So, if they asked me what would I see it do?

Well, there are always the easy things that everyone has been shouting about: running non-proprietary software, connectivity, multi-tasking. But what I really want a device like this is portability. Not how I can carry it around, but what it can connect to while carrying it around.

I want to take my pad to a desk with a keyboard on it, put the pad in a holder and start typing. While I type, the keyboard station is charging my pad. After finishing my document I pick up my pad and go to the printer. Pressing one button on the printer and one on my pad I am printing the document. I want to hand my document to someone else, I bring my pad to theirs and another button press, my document is now on their pad. I want to collaborate and in a meeting documents are passed electronically between pads. I am in a lecture or briefing and I can submit questions and make comments on distributed materials, answer voting calls.

In my work I want to be able to identify equipment or stock by bringing my pad next to it and updating a network service automatically. The options become more limitless when you consider writing your own applications.

But for now, if I want a nice looking toy, I'll go for an iPad. It'll keep my interest until the next nice toy comes along.

Server 2008 R2 and VMWare vSphere 4

Server 2008 R2 is supported as an experimental product on vSphere 4. As a consequence, there are some gotchas that the boys at VMWare have yet to fix in an official patch. The biggest problem so far is the unexpected and unpredictable lockup on the console. If you want to run Server 2008 R2 on you VMWare box, here is what to look out for:

• Network Drivers - The E1000 driver is alledged to be responsible for server lock up. Once you have created your initial VM, remove the standard E1000 interface that is added by default, and add a new network interface with a vmxnet 3 driver. Now the OS will not have a driver for this, so you will have to install vmware tools before you start doing any network activity. If you are building from PXE you will need to import the vmxnet drivers into your OS building applciation.

• Video Drivers - This is the reason the console will lock up, but only after you have installed vmware tools. When installing vmware tools, do a custom installation. Expand the drivers section and change the video driver option to "This option is unavailable." Continuing without this driver will not affect your experience in the slightest.

Other than this, 2008 R2 virtual machines run well in vSphere 4.