AD attributes to fully Automating OS deployment with WDS (Windows Deployment Services)

Microsoft provides many tools for deploying an Operating System (Windows 7, Windows 8, Windows Server 2008, Windows Server 2012).  Each has their pros and cons.  Some are easy to setup some a little harder.

One thing I found over the years at Microsoft was when setting up a test system that is physical hardware it is best to do a clean install, thus using WDS. 

The info below was used as part of the Automation system I developed while at the Microsoft Enterprise Engineering Center.  By using WDS with the automation system we were able to simply click on a server in the UI and select Image.  This would then kick off the OS Imaging workflow.
Deployment Steps:

1. Power Server off (via Raritan Switched PDUs and SNMP)
2. Move Network interfaces for server into correct Vlan (via Network Vlan plugin system)
3. Set Active Directory Attributes below for WDS
4. Set KVM interface Name (via Raritan Command Center APIs)
5. Power Server ON (via Raritan Switches PDUs)

 Advantages of using WDS

• No image to maintain for each model
• No images to patch each month
• System is clean and pure
• Bases (install) images are easy to setup (just need the .WIM from the CD)
• Does not require agents to be installed on everything
• Allows for an easy system audit script to be run at the same time
• Don't have to worry about a "safe OS" being installed on some drive

I am not going to go into detail on how to setup WDS or add boot or install images.  This is well documented on MSDN. http://technet.microsoft.com/en-us/library/jj648426.aspx.

I don't recommend using Stand-alone mode if you need a system that needs some resiliency.  The AD integrated option works the best!

A few requirements

• WDS is setup with a boot and install image (and you know the names(
• You have a computer object created with the UUID (netbootGuid) property set

We will be working with 2 AD attributes

• netbootMachineFilePath - http://technet.microsoft.com/en-us/library/cc753134(v=WS.10).aspx
• netbootMirrorDataFile - http://msdn.microsoft.com/en-us/library/dd871382.aspx

netbootMachineFilePath

This attribute specifies what PXE client should be used when the computer boots.  You can use wdsutil /Set-Device /Device:<name> /BootProgram:<path> to set this.

3 common values

• <WDS Server FQDN>\boot\x86\pxeboot.n12 - Tells the PXE client to NOT required F12. If you used the N12 option be sure to run "wdsutil /set-server /resetbootprogram:yes" on the WDS server. If you don't the clients will always be in reboot loop.
• <WDS Server FQDN>\boot\x86\abortpxe.com - Tells the PXE client to abort any PXE boot attempt on that NIC and move to next device in boot order
• <WDS Server FQDN>\boot\x86\pxeboot.com - Tells PXE to request the user to push F12.  Will move to next boot device if they don't.

netbootMirrorDataFile

This attribute holds the following items for a ZERO Touch deployment.

• What boot file (WIM) to use - BootImagePath
• Path to unattend XML file (provides path to install WIM) - WdsUnattendFilePath
• If you want the computer joined to the domain - JoinDomain

As MSDN provides (in link above) the info is in Key=value; format.

Example: to use boot image foo, unattend bar and NOT join the domain

netbootMirrorDataFile=JoinDomain=0;BootImagePath=Boot\x86\Images\foo.wim;WdsUnattendFilePath=wdsclientunattend\bar.xml;

 Note the trailing ;.  See http://www.mikepoulson.com/2013/08/bindlsvc-error-522-from-wds.html for more info.

These items can also be set by running the following WDSUtil commands

• WDSUTIL /Set-Device /Device:<name> /WDSClientUnattend:<path>
• WDSUTIL /Set-Device /Device:<name> /BootImagePath:<path>
• WDSUTIL /Set-Device /Device:<name> /JoinDomain:No

WDS and Symbolic Links

Windows Deployment Services (WDS) is all my team and I use for OS deployments. We regularly use the $OEM$\$1 option to copy files and scripts to the target install. More on $OEM$

Recently we started updating scripts that are in a $OEM$, $$ or $1 folder. This was very time consuming because you had to update a large number (~50) different images.

The solution to this problem: Hard Links http://msdn.microsoft.com/en-us/library/aa365006(v=vs.85).aspx
We use the Mklink command to create a Hard link to a “source file”. WDS follows this link and copies the script\file to the target OS during install. This allows us to have a GOLD set of scripts that will get copied yet we only have to make a change in 1 location.

The important thing when making the link with mklink is to pass the /k argument. This will tell mklink to make a hard link not a Symbolic link. You can find more on Mklink at http://technet.microsoft.com/en-us/library/cc753194(WS.10).aspx


WDS will not work with a Symbolic link and will throw an error like:
Windows cannot copy files from \$OEM$ to C:\$WINDOWS.~LS\Sources. The files do not exist. Make sure all files required for installation are available, and restart the installation. Error code: 0x80070003]


This works on Windows Server 2008, Windows Server 2008 R2.

IPv6 6over4 tunnels with Windows and Cisco

Repost from old blog
A few years ago I began working with Art Shelest here at Microsoft to get Native IPv6 running in my lab.  After a few weeks we had it up and running. 
We had to work with MSIT (was known as ITG at the time) to get a 6over4 tunnel setup so that we could connect to the 6bone even though my upstream routers did not support IPv6 (still don't at this time).  Once the tunnel was setup on the ITG Router we ran a command on my Windows IPv6 Router in my lab and it was up and running. 
We run our entire lab IPv6 network on Windows Routers.  We use Windows Server 2003 but you could use Windows XP Pro if you wanted.  Unlike RRAS the IPv6 routing stack is included in Windows XP.  And after Windows XP SP1 this stack was fully supported by Microsoft support.  So if you follow the steps at http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_lab_node.mspx you can get your internal test network setup.
Now to create a 6over4 tunnel to another router you simply run the below commands from a cmd prompt on your main IPv6  router

1. netsh
2. int ipv6
3. add v6v4tunnel interface="V6v4 Tunnel" localaddress=<local ipv4 address> remoteaddress=<remote ipv4 address>
4. set interface "v6v4 Tunnel for=en
5. add address int="v6v4 tunnel" address=<IPv6 address from provider>
6. add route ::/0 "v6v4 tunnel" <remote IPv6 address> publish=yes

Key things to note with the above

• The Local IPv4 address is the IP address that the tunnel is going to use to talk to the Upstream V6 Router (With my example below it would be 1.1.1.1). 
• The Remote IPv4 Address is the IP address of the upstream V6 router (with my example below it would be 2.2.2.1).
• The IPv6 address from provider would be a IPv6 address that you get from your v6 provider (with my example below it would be 3ffe:ffee:100:2::2)
• The Remote IPv6 address is the IPv6 address of the upstream IPv6 router (with my example below it would be 3FFE:FFEE:100:2::1)

The Cisco side of the config looks like this
interface Tunnel1
 description v6in4 tunnel to  lab 1.1.1.1/3FFE:FFEE:100:2::2
 no ip address
 ipv6 address 3FFE:FFEE:100:2::1/64
 tunnel source 2.2.2.1
 tunnel destination 1.1.1.1
 tunnel mode ipv6ip



Once the machines are all setup important things to know are "how do you back up your ipv6 configuration?" Well with netsh it could not be easier.
Simply run 'netsh int ipv6 dump > c:\ipv6backup.txt'  this will dump all the ipv6 config out to the txt file.  Now if the router was to ever go down you can run the command  'netsh exec c:\ipv6backup.txt'.   With these 2 commands it will backup and restore your ipv6 configuration..  You can also modify the backup command to be 'netsh dump > c:\netshbackup.txt' and it will back up 99% of all the settings for your network configuration.
If you would like to know more about how I have my IPv6 network setup please let me know.  Also I recommend the Microsoft Press Book Understanding IPv6 (http://www.microsoft.com/MSPress/books/4883.asp) ISBN: 0-7356-1245-5

L2TPv3 performance tweaks for HyperV GeoCluster Live Migration

L2TPv3 is a great feature for extending a Layer2 network across sites. This is very useful when you are using Live Migration with HyperV or when you want to pass traffic (at Layer 2) to a different location. 

 

Recently while working on a SAN GeoClustering test case we want to do a stretched VLan from one lab to another (in different buildings). This gets tricky because we (my team) don’t own or manage the network infrastructure between these buildings. Many companies will use MPLS/VPLS to create a VPN or VLL (Virtual Leased Line) between two sites. This can be expensive and a pain to get setup if you only need a link for a short period of time.

 

Stretched VLans are becoming more and more common as feature like Live Migration allow the moving of a system from one datacenter to another at the push of a button (well mouse clicks). 

 

The setup:

Sites: We were testing at labs that are about &frac14; of a mile apart from each other on opposite sides of Main Campus

 

The test network consisted for 4 vlans. These networks were duplicated at both sites

·         Public -- internet facing for request to HyperV hosted servers

·         Cluster – heartbeat network for Fail over Cluster

·         Live Migration – network to pass server state during live migration

·         Management – backend network to access remove desktop to servers and devices

 

Servers: We had 6 physical servers for the test (3 at each site). Each site had the same setup for servers

·         Server 1 – Host infrastructure systems (AD, DNS, DHCP, WDS)

·         Server 2 &3 – Fail over cluster hosts that would host the workload VMs

 

To interconnect the 4 vlans across buildings we uses the existing IPv4 infrastructure and 2 cisco routers. The building infrastructure offers > 1gbps in an out of each lab, so we connected with 1gig interfaces to uplinks. We also do not have visibility into MTU on building (intra and inter) infrastructure.

 

So down to what we found and what we changed:

Original Setup (poor performance): - config shown below

·         Single L2TPv3 Tunnel between sites

·         Lab facing interfaces were connected to switch that was a trunk port allowing our 4 VLans

          o   Switchport mode trunk

Original design findings:

·         Traffic passed (with 802.1q tags) correctly through tunnel

·         MAX bandwidth when coping files/Live Migration from site to site was 20-30mbps

·         Large amount of dropped packets in queue

·         CPU maxed at 100%

 

Tweaked design (best performance)

·         4 tunnels (one for each vlan) using sub interfaces

·         No change to switch trunk config

·         Modified hold-queue on each physical interface

·         Enabled MTU tuning on pseudowire-class (ip pmtu)

·         Enabled Don’t Fragment bit on pseudowire-class (ip dfbit set)

Tweaked design Findings:

·         Traffic passed correctly through tunnel

          o   Each VLan correctly mapped on either side

·         MAX bandwidth when coping files/Live Migration from site to site was ~800mbps

·         CPU would be around 40%

 

Original Config (each site was identical except swapped xconnect ip with interface ip address) – SLOW!

---

l2tp-class class1

authentication

password 0 123456789

!

pseudowire-class ethernet

encapsulation l2tpv3

protocol l2tpv3 class1

ip local interface GigabitEthernet0/1

!

interface GigabitEthernet0/0

no ip address

duplex full

speed auto

no cdp enable

xconnect 10.216.44.47 125 pw-class ethernet

!

interface GigabitEthernet0/1

ip address 10.197.251.215 255.255.255.240

duplex auto

speed auto

no cdp enable

!

ip route 0.0.0.0 0.0.0.0 10.197.251.209

!

no cdp run

!

End

 

Tweaked Design

--

l2tp-class class1

authentication

password 0 123456789

!

pseudowire-class ethernet

encapsulation l2tpv3

protocol l2tpv3 class1

ip local interface GigabitEthernet0/1

ip pmtu

ip dfbit set

!

interface GigabitEthernet0/0

no ip address

duplex full

speed auto

no cdp enable

hold-queue 2048 in

hold-queue 2048 out

!

interface GigabitEthernet0/0.2996

encapsulation dot1Q 2996

no cdp enable

xconnect 10.216.44.47 126 encapsulation l2tpv3 pw-class ethernet

!

interface GigabitEthernet0/0.2997

encapsulation dot1Q 2997

no cdp enable

xconnect 10.216.44.47 127 encapsulation l2tpv3 pw-class ethernet

!

interface GigabitEthernet0/0.2998

encapsulation dot1Q 2998

no cdp enable

xconnect 10.216.44.47 128 encapsulation l2tpv3 pw-class ethernet

!

interface GigabitEthernet0/0.2999

encapsulation dot1Q 2999

no cdp enable

xconnect 10.216.44.47 125 encapsulation l2tpv3 pw-class ethernet

!

interface GigabitEthernet0/1

ip address 10.197.251.215 255.255.255.240

duplex auto

speed auto

no cdp enable

hold-queue 2048 in

hold-queue 2048 out

!

ip route 0.0.0.0 0.0.0.0 10.197.251.209

!

no cdp run

!

 

Configuring Dell EqualLogic management interface

The Dell EqualLogic iSCSI SAN supports an out-of-band management network interface. This is for managing the device from a separate network than the iSCSI traffic is on.

The documentation for the PS6000E is some of the worse I have ever seen. In addition to that the CLI (command line interface) is about as bad as a big pile of dog poo.

 

 

So this is a quick set of commands that are used to configure the management (eth2) interface on the device. The web interface is nice and all but you have to have your 10Gig network setup before you can access it. Also the "setup" does not really give you an easy option to configure the management interface.

 

 

Steps:

Login to Console Port with grpadmin username and grpadmin password.

After you run setup you will need to know the "member name". You can get your member name by running the "member show" command. This will list the name, Status, Version, Size information for each member configured on the array.

 

grpname> member show

Name Status Version Disks Capacity FreeSpace Connections

---------- ------- ---------- ----- ---------- ---------- -----------

EEC-DellEqual online V4.3.6 (R1 16 621.53GB 0MB 0

grpname>

The member name for my device is EEC-DellEqual.

Once you know the member name you will need to set the IP address for your management interface. This IP address will need to be one that you can access from your management network. The port is an untagged port similar to other out-of-band management ports on devices (network switches).

To configure the IP use the member command again.

First set the interface to be management ONLY

-member select EEC-DellEqual eth select 2 mgmt-only enable

Set the IP address and Network Mask

-member select EEC-DellEqual eth select 2 ipaddress xxx.xxx.xxx.xxx netmask 255.255.255.0

Enable the interface (by default the MGMT (eth2) interface is disabled and will not provide a LINK).

-member select EEC-DellEqual eth select 2 up

You will be asked to confirm that you wish to enable the Management port

This port is for group management only. If enabling, make sure it is connected to a dedicated management network. If disabling, make sure you can access the group through another Ethernet port.

Do you really want to enable the management interface? (y/n) [n] y

To view current IP and state of an Eth interface use

-member select <member Name> show eths

Once that is complete you can use the management IP address to create an http or https connection to the Array.