Monthly Archives: January 2011

Allow Access to a Dell Remote Access Controller (DRAC or iDRAC) through a firewall

It’s Friday, 4:59pm and you’re itching to get home, that’s when you get a call saying that the server in the remote office is locked up. All the employees of the branch office have left for the day and shutdown all of their PCs. There’s no way to get into that local network and remote control the server or reboot it without fighting through rush hour traffic, trying to remember the security code to the front door, and then playing the ‘see which key fits game’ on 3 sets of locked doors. This could be avoided if you had just opened access to your DRAC to your IP ranges at your main office. Here’s how:

First Identify what ports your version of the Dell Remote Access Controller uses, here’s a short list:

443TCP (I recommend changing this from within the DRAC’s UI)

443TCP (I recommend changing this from within the DRAC’s UI)

iDRAC 6 & iDRAC 7
443TCP (I recommend changing this from within the DRAC’s UI)

For this example I’m going to be using a SonicWall TZ 210 Router, and we’re going to be Setting up access to a iDRAC 6 that’s IP address is

I’m also going to be adding all of these services into a Service Group, that way I only have to make 1 set of firewall and NAT rules instead of 3. If your firewall does not support this, just make 3(or 5) individual rules, one for each service.

The first thing I’m going to do is change the DRAC’s internal web server to use port 4433 instead of port 443, because I’m already running services over port 443 for something else, and more than likely you are too.

You change this by logging into the DRAC, under the Network/Security section there will be tab for Services Change the HTTPS port number to 4433.

Next let’s create the services, On the Sonicwall. Log into the Sonicwall and on left hand

Figure 1.

pane, expand Firewall, and click Services. Click Add… to Create a new service, enter a name, I typically use DRAC Service 1 or something similar. Change the Protocol to TCP, and Enter your Port range, for the first service we’d enter 623 and 623 again in the second box See Figure 1.

Figure 2.

Once you’ve created all 3 Services you can create a new Service Group, I called mine DRAC Services, and I add all 3of the services that we just created to this group. See Figure 2.

Next we’ve got to create some address objects. Expand the Network on the Sonicwall’s left hand pane and click Address Objects. Click Add… to create a new Address Object. We’re going to need to create two address objects. One for the DRAC which will be and located on the LAN, and the other will be for Our (Your) main office’s public IP(s) and will be located on the WAN. You’re Address Object for the DRAC should look like figure 3.

Figure 3.

Next we’ll create our Firewall rule, expand Firewall on the Sonicwall’s left hand pane

Figure 4.

and click on Access Rules. We’re going to be creating a new rule from the WAN to the LAN. When you create the rule it should look like Figure 4, only with slight changes to the names of the Address Objects you created.

Action: Allow
From Zone: WAN
To Zone: LAN
Service: DRAC Services( or whatever you named your service group)
Source: This will be whatever you named your Main Office’s Public IP address Address Object
Destination: WAN Primary IP (this is because you’ll be accessing the DRAC from the Public IP of the remote office and not from it’s Internal IP address)

We’re almost done now, we just need to create our NAT rule, and then we’ll be ready to test.

Expand Network on the Sonicwall’s left hand pane, and click on NAT Policies. Click

Figure 5.

Add… to create a new NAT rule. You’re NAT rule should look similar to Figure 5.

Original Source: This will be whatever you named your Main Office’s Public IP address Address Object
Translated Source: Original
Original Destination: WAN Primary IP (this is because you’ll be accessing the DRAC from the Public IP of the remote office and not from it’s Internal IP address)
Translated Destination: This will be whatever you named your DRAC’s Address Object.
Original Service: DRAC Services( or whatever you named your service group)
Translated Service: Original
Inbound Interface: Any
Outbound Interface: Any

That’s it! You should now be able to go to https://YourBranchoOffice’sPublicIP:4433 and log into your DRAC. Note: I’ve had some issues with the iDRAC6 Active X control not working remotely, change it over to Java and it works fine. I’m not sure if this is an issue with just my PC or with something within the Active X control. Let me know if the Active X control works for you after you’ve followed these instructions.

Internet Explorer 8 continually asking users to log into web sites in Terminal Services (2008 R2)

Ran into a super painful problem about 3 weeks ago. When users were logged onto a Terminal Server (Server 2008 R2) and running Internet Explorer 8 (Why, you ask, would I allow IE to run in Terminal Services? Normally I wouldn’t but the client’s app needs to be run within IE) any time they tried to download a file, or open a link that moved them to a new tab or window, the site “forgot” who they were and prompted them to re-authenticate.  This happened on many different sites, and not just on the app I mentioned.

We started down the normal troubleshooting path, allowing the site in Pop-up blocker, adding the site to the Trusted Sites list, lowering the security on the Trusted Sites list to “Low”, enabling Computability Mode, etc. Nothing would allow the file to be downloaded without having to re-login to the site.

As we continued testing, we removed all Group Policies that were locking down the Terminal Server, we created new users with fresh profiles, and double checked registry and file system permissions, again nothing would resolve the problem.

Finally, we came across this blog post over at the MSDN site, Here. Turns out, that when a new tab is opened, it starts running under a different process, combine that with users running on a Server 2008 R2 without “Power Users” permissions, like in the case of Terminal Services, and it creates a situation where the new process does not have permission to access the cookie that was stored by the other running process. This is not the case on Windows 7, as users without “Power Users” permissions don’t experience this same problem.

Internet Explorer changes it’s behavior of where it stores cookies and other data depending on the permissions for the user running the process. Any application which launches a new tab, in turn launches a new process and this will not have permission to access data like cookies from the process which launched it. Since the users are in a locked down environment, this Internet Explorer behavior should be turned off.

The registry value that we needed to change was located here:


We needed to create a new DWORD called “TabProcGrowth” and set it’s value to 0.

The reason we are setting this value at HKLM and not HKCU is so that every users who uses this machine will have this setting applied to them. I’m far too lazy to change it and every user’s HKCU level.

After making this changed we were able to log in with new test users, and existing users alike and verify that we were no longer seeing the problem!

Deploying Windows Deployment Services & Windows XP (WDS) Walkthrough

This is my First walkthrough guide that I’m posting up here at the site. This was done a few years ago, and I realize that Windows XP is now taking a second row seat behind windows 7, however I know that many companies are going to keep using it for the next few years, and it certainly helps to be able to roll out (almost)zero touch Windows XP images alongside your Windows 7 Images. So here goes:

Deploying Windows Deployment Services & Windows XP (WDS) Walkthrough

  1. Overview
    1. Assumptions
    2. Network Design
    3. Preparations
  2. Installation
    1. Concerns
    2. Installing Software
  3. Pre image configuration
    1. Configuration of server
      1. WDS
      2. DHCP
      3. Configuration
  4. Configuring a PC for an Image
    1. Preping a PC
    2. Staging Active Directory
  5. SysPrep and Image Capture
  6. Configuring an image in WDS
    1. Post Capture Configuration
    2. Making Changes
  7. Deploying (Almost)Zero Touch Images
    1. Creating an unattended installation
    2. Testing


  • Assumptions

I’m writing this guide with the assumptions that you’ve gone through the process of deploying software via group policy before and that you have an understanding of imaging and the problems related to HALs. I’ve also planned on using only Open License software for this deployment as I have not had success in getting OEM software working as outlined in this guide. Finally I’m making the assumption that this is a domain environment and that the machines being imaged are all the same make and model. The server should be partitioned with two drive letters C: and D:

This guide was produced with the intention of creating a “self service portal” where laptop users could bring their laptop and have it “refreshed” with the most recent image created by the IT department. This was intended as a mostly hands off approach where users could plug in their laptops, hit F12, grab a cup of coffee and when they get back they will have a fresh installation of windows.

  • Network Design

In my setup I’ve created a domain environment where the Domain Controller has two network cards installed. One network card is connected to network 192.168.1.x/24 and is our normal Local Area Connection, used for normal everyday production network (referred to as Production network going forward). The second network card is 172.16.1.x/24 and is plugged into a secondary network that does not have access to the production network. This network is for use with Windows Deployment Services (referred to as WDS network going forward).

The Prodction Network will be used for configuring the client machine, testing the software, joining the domain, and all other tasks related to prepping the client machine for production use. Once the client machine is properly prepped it will be SysPreped and moved over to the WDS network in order to capture the image. The WDS network was configured so that normal production machines could not accidentally “refresh” themselves, machines would need to be physically moved to the WDS network in order to do this. Adjust this guide to fit your design needs.

The WDS server is and respectively. It is running DHCP, DNS, and WDS, it’s all running a basic RRAS setup with just basic routing between the WDS and Production networks.

  • Preparations

In order to move forward you should have the following:

  1. Windows XP Open Licenses CD (Pro, tablet, etc)
  2. Windows Vista Business or Enterprise DVD (32 bit)
  3. CDs for all hardware and software applications for client computer
  4. Server 2003 Service Pack 2 installed and running as a Domain Controller(2008 can be used as well)
  5. Networks configured as listed above
  6. External USB Hard Drive


  • Concerns

There are methods available to upgrade from RIS and to install WDS without having service pack 2 installed. This guide does not go over those methods.

This guide relies on DHCP running on the same physical server as WDS is installed in. This guide also relies on Microsoft’s DHCP server.

  • Installing the Software

To install DHCP and WDS: Click Start and then select Control Panel, Click Add or Remove Programs. On the left click Add/Remove Windows Components.  Select Windows Deployment Services and Dynamic Host Configuration Protocol

Figure 1

(DHCP) from under Network Services container. Click Next. Finish the wizard and close out of all open windows.

Open DHCP and create two Scopes one for each network LAN and WDS Make sure each scope binds to the correct NIC card and that both are functioning before continuing, Authorize DHCP. Your settings should look something like Figure 1.

Create a folder on the D: drive to hold all the files that we’ll be working with. Call it something along the lines of WDS_Files.

Download and Install Windows Automated Installation Kit (WAIK) from Microsoft’s website. (you’ll want to grab the Windows Vista version not the Windows 7 version)

Insert your Windows Vista Business or Enterprise CD and copy boot.wim from the Sources\ folder on the CD to the WDS_files folder.

Download and extract the from Microsoft’s website or an XP CD. Put all of the files in a folder called SysPrep under the d:\WDS_files\ folder.

Click on Start and then All Programs, Choose Administrative Tools, and then select Windows Deployment Services.

Pre Image Configuration

  • Configuration of Server

Windows Deployment Services Configuration

In the MMC Console expand Servers and select your server. Right click your server and select Configure Server. Click Next at the initial screen. Choose D:\RemoteInstall as the installation directory and click Next. On the DHCP Option 60 screen, select Do not listen on port 67 and Configure DHCP option 60 to “PXEClient” Click Next. Select Respond to all (known and unknown) client computers. (we’ll change this setting later for security and functionality). Choose not to add images now. Click Finish.

DHCP Server Configuration

After the wizard finishes Right Click on the server in the WDS mmc and choose properties. Click the DHCP tab. Make sure both options are checked.

Open the DHCP admin console and configure an additional option on the WDS scope, Option 60. Leave this option with default settings and then remove this same option from the Server Settings section of the DHCP console. Now only the WDS network card is configured for Option 60 but the LAN network card is not. Exit DHCP.

Configuration of WDS options

Open the WDS MMC Console. Expand until you can see the 4 folders (install images, boot images, legacy images, and pending devices). Right click Boot Images, select Add Boot Image. Browse to D:\WDS_Files\boot.wim. During the wizard name this something along the lines of INSTALL.

Once the Image has been installed Right Click on the image and select Create Capture Boot Image. During the wizard name this something along the lines of CAPTURE and save it in the WDS_files directory.

Right click on the Boot Images folder and select Add Boot Image. Browse to the D:\WDS_Files\capture.wim file you just created.

Right click on the Install Images folder and select Add Image Group. Give this group a name.

Right click on the server within the WDS console and click properties. On the Advanced tab verify that Yes, I want to authorize the Windows deployment Services server in DHCP is selected.

The WDS aspect of the server configuration is now complete

Configuring a PC for Image

  • Preping a PC

Install windows from the Open License media and install all drivers

Join computer to the domain and deploy any applications necessary to the computer either by Group Policy or off of CD. Name the computer something easy to locate in AD and that is not part of your final naming convention (ex. WDSclient)

Configure the PC with any custom wallpaper, power settings, Desktop Theme, etc. Once finished restart the computer and log in as an administrator copy the configured profile to the Default Profile folder and set proper permissions. I use the Everyone group by default.

Copy the sysprep folder from the server to the C:\ drive of the client computer.

  • Staging Active Directory

Boot a client PC and press whatever key is necessary to PXE boot during the boot device screen. During this time the GUID of the PC should be displayed. Write this GUID down, it may be necessary to reboot and try again if there is not enough time to get the GUID during the first try. Some manufactures will display the GUID in the bios, you can also check there.

In Active Directory go to the OU where you want new client computers to be placed and Right Click, Choose New Computer from the pop up window. Enter the Computer’s unique name, click Next, click This is a managed computer, Enter the computers GUID without the dashes. Click Next. Select Any Available remote installation server. Click Next. Click Finish. Repeat for all computers that will be using WDS, this only needs to be done once per unique piece of hardware regardless of how many times that machine is reimaged.

SysPrep and Image Capture

Run C:\sysprep\setupmgr.exe on the client PC.

On the welcome screen click Next. Select Create New and click Next. Select Sysprep setup and click Next. Select Windows XP Professional (assuming your using any flavor of windows XP pro, tablet edition included) click Next. Click Yes, Fully Automate the Installation. Click Next. On the First Screen enter your name and organization, click Next, On the display Settings section click Next, set your time zone and click Next, Enter your Open License cd key and click Next, on the computer name section enter %MACHINENAME% and click Next, on the password section select Use the following Administrator Password (127 characters maximum; case-sensitive): and leave both boxes blank (this will keep the password you already configured when setting up the PC make sure to use a strong password on the PC before taking an image) click Next. On the Networking Components section click Next, on the domain section highlight domain and enter the domain name, Select Create a computer account in the domain. And enter a domain account and password (don’t worry this will be removed in a minute) Click Next, on the Telephony section enter the proper settings, click Next, Click Next 5 more times, or enter custom settings if you wish. Click Finish.

When prompted save the sysprep.inf to the server’s WDS_Files directory.

Edit the sysprep.inf in notepad

Change the [Identification] section to look like this:


Save the sysprep.inf file in the WDS_Files directory.

On the client PC run c:\sysprep\sysprep.exe. Select use Mini-Setup and change shutdown mode to Shut down. Click Reseal. The PC will now turn off.

Unplug the client PC from the LAN network and plug it into the WDS network. Plug in your external USB hard drive. Boot the PC and quickly enter the PXE boot mode by pressing F12 on most PCs. When prompted by WDS press F12 again to enter WDS setup.

You should be brought to a black and grey screen titled Windows Boot Manager. If you followed the steps above you should see two options. Install and Capture. Select Capture.

At the Welcome to the Windows Deployment Services Image Capture Wizard click Next. Choose C: from the Volume to Capture drop down. Name your image something appropriate. Enter a Description and click Next, on the Image Capture Destination section choose to save on your External USB hard drive.  Give the image a simple short name. Click Upload image to WDS server: enter the server’s name and click connect. Enter the domain\username of the administrator and click ok. Select the image group from the drop down and click Finish.

Turn the PC off when finished uploading.

Your image should now appear in WDS under the image group that you created earlier.

Configuring an Image in WDS

  • Post Capture Configuration

Open Windows Explorer and browse to D:\RemoteInstall\Images\[Image group name you created]\

Note the name of the wim file in this directory create a new folder with the same name as the file but without the .wim at the end. Example: WindowsXP.wim would need a folder called WindowsXP.

Open this new folder so that you are in D:\RemoteInstall\Images\[Image group name you created]\[Image name folder]\   Create a new folder called $OEM$ and inside that $OEM$ folder create a new folder called  $1 and inside that $1 folder create a folder called sysprep. Your path should now look like this:

D:\RemoteInstall\Images\[Image group name you created]\[Image name folder]\$OEM$\$1\sysprep\ Copy and paste the sysprep.inf from D:\WDS_Files into this directory.

  • Making Changes to an already captured image file

Note: You’ll need to Right click on an Image in WDS, Export it, then edit it using the steps below, afterwards you’ll need to re-import it and either replace the existing or rename it to a new one.

Browse to C:\Program Files\Windows AIK\Tools\x86 folder, right-click wimfltr.inf, and select Install.

Create a folder on D: called Mount

Open Command Prompt and move to C:\Program Files\Windows AIK\Tools\x86 issue the following command to open a image called xp.wim with read/write permissions:

Imagex /mountrw d:\RemoteInstall\Images\[Image Group]\xp.wim 1 d:\mount

Note: to open it in read only mode us /mount instead of /mountrw

Now the contents of the mount folder are the contents of the image file. Make your changes or add/remove files and then issue the following command to save:

Imagex /unmount /commit d:\mount

Deploying (Almost) Zero touch Installations

  • Creating an unattended installation

In the WDS mmc console click on Boot images, Right Click on Capture and choose Disable.

We now need to create an unattend.xml file we would normally use Windows Automated Installation Kit for this but it does not support Windows XP images so we’ll make one from a template:

Use notepad to create a new unattend.xml in D:\RemoteInstall\WdsClientUnattend

Enter the following but make changes to the parts in BOLD: You can download an Rich Text File here: unattend_xml, edit the parts that are bolded, and copy the entire contents into notepad, save as an XML file.

One the unattend.xml file is configured open the WDS mmc console. Right Click the server and choose properties. On the Boot tab under Default boot image (optional) click Select… and then choose INSTALL (boot.wim) from the list. Click the Client tab. Check Enable unattended installation click the browse button and browse to D:\WdsClientUnattend\unattend.xml. Click Apply and then click OK.

  • Testing

Boot a client computer while connected to the WDS network without a USB hard drive attached. Press F12 to boot from the Network (PXE). Press F12 again to boot from WDS server. From this point forward the installation should be unattended and it should format the hard drive on the PC, make 1 partition for drive C: and use all space. It should then copy the image over to the PC, use it’s GUID to obtain a PC name from Active Directory, name the PC, join the domain and reboot. When it is done rebooting users should be able to log into the domain and use the applications configured before the sysprep was run. All PCs that have been pre staged in AD should perform this same process

Note: If the installation does not automate itself during the join domain section you can follow the steps listed above to edit the image and place a copy of the sysprep.inf in the c:\sysprep folder on the client image. This should take care of the problem and the file will be deleted after the machine joins the domain.

Attached Files:

Creating a new Outlook 2011 Profile (Identity )

The first thing to remember is Outlook 2011 is the first Outlook version on Mac, it’s a replacement for Entourage, so when searching for how to create a new Profile, you’re really searching for how to create a new Identity, that’s what Entourage used to call them. If you’re coming from a Windows environment (like me) then you’ll just be calling it a Profile, but that’s why you’ve ended up at my post instead of somewhere else, you’re calling it by the wrong name.

Whatever you want to call it, you can change it and Delete it by going to the following location:
Open Finder
Click on Applications
Open the folder "Office 2011"
Open the folder "Add-ins"
Open the "Microsoft Database Utility"

You can use the Plus and Minus at the bottom to add new or remove Identities (Profiles) for Outlook 2011