JasonSamuel.com

I urge you to read my PVS 6.1 on XenDesktop/Windows 7 guide first. Read it and make sure you understand it. The same concepts and most all procedures apply to Server 2008 R2. So I am not going to get as detailed on PVS technology in this article. This is going to be more XenApp centric. If you don’t have a thorough understanding of PVS, it is easy to become lost so please make sure and read that article and go through those screenshots first.

Citrix has an excellent eDoc primer for understanding the intricacies of XenApp on PVS located here. I recommend skimming this before beginning:

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-image-prep.html

Now on to the steps. This is just my way of doing it. It works well for me. There are a couple of different ways you can achieve the same thing so use what works for you:

1. I am assuming you already have a XenApp 6.5 farm created and at least one dedicated server for the role of the ZDC. All XenApp servers provisioned via XenApp will be member servers of this farm and you do not want them to become a ZDC. Just set the election preference in AppCenter under Zones. In this example, I have a Default Zone and have set one server as the ZDC but it is best practice to have at least a handful of servers that are not provisioned to be set as preferred. Just in case one goes down, you don’t want one your provisioned servers to become a ZDC:

2. Now go to your XenServer and create a new Server 2008 R2 VM

3. Install XenServer Tools

4. Make a copy of the VM and convert it to a template. This is your “clean” Server 2008 R2 image you can come back to later if you need to. You can spin up new VMs from it.

5. Now go back to the VM you were working on and install things that are needed on all servers like Symantec, Citrix Offline Plugin (if you intend to leverage app streaming), etc. but try to keep it as clean as possible. Remember, you are building just the base right now. Don’t install any applications you plan to publish yet.

6. Add the server to the domain. Make sure the name is the first server in your naming scheme, example: “ServerName-100″ where 1 denotes the image number and 00 is the VM number. The next VM that gets spun up using this image will be ServerName-101 and so on.

7. Begin installation of XenApp 6.5 like normal and follow Approach 3 detailed here:

http://support.citrix.com/proddocs/topic/xenapp65-install/ps-image-prep.html

8. If you have multiple NICs in your PVS environment for streaming vs. regular network traffic there’s an extra step you have to perform in the VM. Make sure you go into ICA Listener properties and set it to PVS Adapter #1, the network NIC. Not the PVS streaming NIC which is #0. They may be labeled differently in your environment depending on the NIC order of your VM. Just remember, you want the network NIC to handle ICA, not the streaming NIC.

9. Now install the apps you intend to publish. Just install, don’t try publishing anything yet. If you plan on streaming apps to your XenApp servers via Citrix Offline Plugin or App-V, skip this step.

10. Install the PVS Target and reboot. Do not run Imaging Wizard yet.

11. You can choose to install the EdgeSight agent at this point if you use EdgeSight in your environment. There is an excellent guide from Citrix on how to install EdgeSight in a PVS environment below. Don’t worry, when it detects the PVS Target software is on the system and the image is in private mode being updated, it won’t start the EdgeSight service and start sending your EdgeSight server junk data:

http://support.citrix.com/proddocs/topic/edgesight54/es-agent-install-streamed.html

12. Log back in to the VM and in the XenCenter console, set the PVS boot disk to boot first (BDM). Then go to the PVS Console on the PVS server and create a new Device with the MAC address of this VM’s provisioning/streaming NIC. Call the device ServerName-101 so it’s separate from the ServerName-100 original but call the vDisk 100 so you know where the image came from later (i.e. image 1). Set device to Boot from Hard Disk. Now reboot the VM. You can let Imaging Wizard do this but if you really want to be hands on, you can choose to create and attach an empty vDisk of the same size as the c: drive of the VM now.

13. It should have booted from the BDM boot disk and be connected to the empty vDisk you created. Run Imaging Wizard and push the image across to the PVS Server vDisk (don’t forget to optimize the image). If you did not create a vDisk in the above steps, just create a new disk and run through the Wizard prompts to create it real quick. It will assign the device to this new vDisk. Reboot when you are asked to.

14. Log back in and immediately XenConvert will launch and begin pushing your image over to the newly created vDisk.

15. Now go to the PVS console and set your device to boot from vDisk and reboot your VM. It should now be booting from your vDisk.

16. Log back in and re-run XenApp configuration and unjoin from farm using the prep option. This is done by going to Start > Programs > Administrative Tools > Citrix > XenApp Server Role Manager > and then clicking on the XenApp Server Role Manager app. Click Edit Configuration. Then click Prepare this server for imaging and provisioning. You want to just leave the defaults checked which is to remove it from the farm and join on the next boot. Once it removes it, it will ask you to reboot. Just close and power down the VM, don’t reboot.

17. Go to your PVS server and change the vdisk from private to standard mode. Now spin up a few VMs using the “Streamed VM Setup Wizard” in the PVS console. You’re going to need a template and you’re going to want to setup your write cache. I’ve covered this very well in my PVS 6.1 on XenDesktop/Windows 7 guide so I’m not going to get into the details here. Wait until the VMs are created and powered on.

18. Go to your ZDC and open up AppCenter and run a Discovery. You should see the new member servers. At this point you can begin publishing or streaming apps to them.

TO MAKE CHANGES AND RESEAL THE IMAGE
1. Boot a device into maintenance mode after creating a maintenance version on the vDisk. Or you can choose to power down all your running VMs and put the disk into private mode. Your choice.

2. Make your changes.

3. Re-run XenApp configuration and unjoin from farm using the prep option.

4. Shut it down and promote the image to production if using versioning. Or put the disk back into standard mode if you used the other method.

5. Reboot all your devices so it gets the new vdisk

I hope this guide helps. Please feel free to leave a comment below if you have any questions. I’ll try and help as best as I can.

Let’s say you decide to decommission your Remote Desktop Services (RDS)/Terminal Services Licensing Server or you moved your TS/RDS CALs to a different server. That means you need to change the name to the new server under Remote Desktop Session Host Configuration on all your XenApp servers.

This is a pain to do manually when you have several hundred XenApp servers. You can do it through group policy but you may only want to change it on a subset of servers in an OU and not all of them. So I used PowerShell and PsExec to precisely target all my XenApp servers I wanted to change. It’s a very quick option when you are pressed for time.

You’ll need to create rds.bat and rds.ps1 and put them in "d:\rdsscript" on the server you plan to run the Powershell script from. You’ll want to share out your "d:\rdsscript" folder on the server you plan on running the script from, otherwise you might get Access Denied errors because the script references a UNC path. The contents of these two files is below.

rds.bat contents:

powershell.exe -executionPolicy unrestricted -command 
"\\yourserver\rdsscript\rds.ps1"

rds.ps1 contents:

Import-Module RemoteDesktopServices
cd RDS:\
cd .\RDSConfiguration\LicensingSettings\SpecifiedLicenseServers
new-item –name newlicenseserver.yourdomain.fqdn
remove-item oldlicenseserver.yourdomain.fqdn -confirm:$false -recurse:$true

Modify the rds.ps1 script with the name(s) of the servers you want to add a the name(s) of the servers you want to remove. You can run rds.bat locally on a XenApp server as a test to see if it worked.

Now it’s time to run it on all your XenApp servers remotely. You can use any number of delivery methods. Again I chose to use PsExec because it’s quick and gets the job done. I highly recommend doing your dev, staging, etc. servers first before doing it in production.

Now copy PsExec.exe into the "d:\rdsscript" folder. You’ll also want to create psexec.bat and xenappserverlist.txt now. Here are the contents of the two files:

psexec.bat contents:

psexec -s @xenappserverlist.txt "\\yourserver\rdsscript\rds.bat" 
pause

xenappserverlist.txt contents:

XenAppServer01
XenAppServer02
XenAppServer03
XenAppServer04
XenAppServer05

So your shared directory on the server you plan on running the script from will look something like this:

Now just double click on psexec.bat and it will run the script on each of your XenApp servers in the list. The “-s” tells psexec to execute as the local system account so you don’t have to put your username and password in the script. I don’t like to put usernames and passwords in the script because doing that would send it across the network in plain text so it may be a security concern.

Hope this helps. Let me know if you have any other methods to accomplish an RDS license server migration quickly. I’m always looking for more options.

You really just want a clean mandatory profile if you are deploying AppSense on Windows 7 or Server 2008 R2. The vast majority of companies don’t need to customize it. When you get into customization, you’re going to go through a lot of trouble trying to clean up the profile. Save yourself the trouble. The best thing to do is have a clean and slim mandatory profile that can be applied to any server or desktop in your environment and leverage AppSense itself to do everything else.

So to build a clean mandatory profile:

1. Login to your Windows 7 or Server 2008 R2 box with a local admin account or an domain administrator account, doesn’t matter. I’m going to use Server 2008 R2 for these screenshots.

2. Start > Control Panel > click User Accounts > click Configure advanced user profile properties

3. Click the Default Profile and hit Copy Too…

4. Copy the profile anywhere you like, I chose “c:\mandatoryprofile.v2”. Usually you want your mandatory profile on a file server or DFS share where it is easily accessible but I am just leaving it local for this example. I specified v2 since I am creating a profile for Server 2008 R2. I changed the “Permitted to use” to “Everyone” so all users get NTFS rights to use it.

5. Navigate to c:\mandatoryprofile.v2 and go to Folder and search options

6. Uncheck “Hide protected operating system files”

7. Now you will 5 temp files you do not need in the mandatory profile. Delete them.

8. The ntuser.dat should be around 512 KB on a clean Server 2008 R2 box

9. Now rename ntuser.dat to ntuser.man

10. From here, you would normally setup a domain level group policy and apply it to the OU that has the servers or desktops you want to use the mandatory profile on. Since this is an example, I am going to edit the local group policy instead.

Go to Start > Run > and type gpedit.msc.

Then navigate to:

Local Computer Policy > Computer Configuration > Administrative Templates > System > User Profiles

There will be 3 items we need to change to “Enabled”:

-Delete cached copies of roaming profiles
-Set roaming profile path for all users logging on this computer
-Prevent Roaming Profile changes from propagating to the server

11. For “Set roaming profile path for all users logging on this computer”, you need to put a UNC path to the share that holds your mandatory profile. So since it’s on the local server in this example, I will do:

\\servername\mandatoryprofile

Notice I did not add “.v2″ at the end. Windows will automatically look for it as the users login.

12. Once you’ve made your changes, it should look like this:

13. Now navigate to:

Local Computer Policy > Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Profiles

There will be 2 items we need to change to “Enabled”:

-Use mandatory profiles on the RD Session Host server
-Set path for Remote Desktop Services Roaming User Profile

14. For “Set path for Remote Desktop Services Roaming User Profile”, you need toy need to put a UNC path to the share that holds your mandatory profile just like the previous setting.

\\servername\mandatoryprofile

Notice again I did not add “.v2″ at the end. Windows will automatically look for it as the users login.

15. Once you’ve made your changes, it should look like this:

16. Now navigate to the mandatory profiles desktop and add a text file. So in this example “c:\mandatoryprofile.v2\Desktop”. I’ve created a file called “This is a mandatory profile in action.txt”.

17. Now right click on the mandatoryprofile.v2 folder and share it out. Make sure “Everyone” has access:

18. Now RDP into the server using any account you like. You will get the mandatory profile and you will see the text file we had created earlier on the desktop.

If you click an application icon on your web interface or storefront site, Receiver will popup and say “Starting…” like normal and if you click for More information, it will say “Connection in progress…”. After about a minute, you will get a popup message saying:

Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. There is no Citrix XenApp server configured on the specified address.

Well that’s odd because you know the app is published. You know the sever is up. You know it’s talking to the ZDC and permissions are good or you wouldn’t be seeing the app. So what’s the issue?

Well one of the common reasons for this issue is that your have multiple NICs on the XenApp server (multihomed server) so there are 2 IP addresses for the server. This is a very common setup in a Citrix PVS environment when running XenApp. One NIC for regular traffic and the other NIC for streaming traffic. But even a regular XenApp environment can have 2 NICs for a variety of reasons. If that secondary NIC is firewalled, on a different VLAN, private, etc. you are going to have problems. That secondary NIC is not meant for ICA traffic but everyone is trying to connect to it. It will time out every time.

A quick way to confirm this from the client side is to click on the application icon again and while it says Starting…, open up a command prompt. Type “netstat” and you should see a SYN_SENT to the server on port 1494. If this IP address is your secondary IP that is not meant for ICA traffic, it will never get a response.

Now go to your server and open up a command prompt. Type “qfarm”. Does your XenApp server show up in the list twice? With both of it’s IP addresses? That’s not good and is another confirmation it’s listening on both NICs.

You can also confirm a third way by going into AppCenter, expanding Servers, clicking on your XenApp server, clicking the Information tab in the right hand pane, and seeing if there are two IP addresses in the “IP addresses” section.

So to fix this, you will need to set your ICA Listener to listen only on the NIC you want regular network traffic to be on.

If you go to Remote Desktop Servers Session Host Configuration, you can double click on the ICA-TCP connection and click the Network Adapter tab. Unfortunately in some environments, you might get an error message saying:

Remote Desktop Session Host Configuration tool is not able to obtain the properties for this connection. The connection has either been deleted or the internal state of this connection has been corrupted. Please close all property pages, and select refresh from the menu.

So to get around this, go to Administrative Tools > Citrix > Administration Consoles > and click on ICA Listener configuration:

Notice how it’s set to “All network adapters configured with this protocol”. Click Edit and go the Network Adapter tab. In the drop down, choose just the NIC you want ICA traffic on:

In my case, I want ICA traffic to be on “Citrix PV Ethernet Adapter #1″. So I will choose that and click OK. Now you can go ahead and restart the IMA Service on your XenApp server but you don’t really have to in most cases. Just try launching your app again and it should come right up.

Sometimes when working on a XenApp server and publishing websites through Internet Explorer, you may have a need to temporarily add the website to the Local Intranet or Trusted Sites zone for testing purposes. Usually NTLM passthrough windows authentication won’t work unless the website is part of the Local Intranet zone. Your users will get a popup box asking for their credentials. In multidomain environments, things can get especially hairy sometimes with the way IE detects a Local Intranet website. You can add the site manually in IE after the website has launched but it’s per profile. If you want to add it for all users on the server, group policy is the way to go. Associating a site with a zone can be accomplished through group policy at the domain level easily but sometimes you just want to test things first and it’s quicker to edit the local group policy on the server.

So to do that on Server 2008 R2, go to Start > Run > gpedit.msc

From there you will see Computer Configuration and User Configuration. We want Computer Configuration. Drill down to:

Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page

Double click on Site to Zone Assignment List and click the “Enabled” radio button.

Then click “Show…”

A new box will pop up. For the Value name, you want to type in the name of your website. For the Value, you want to specify a number 1 through 4. These correlate to the zones which are:

1. Intranet zone
2. Trusted Sites zone
3. Internet zone
4. Restricted Sites zone

Hit OK to both windows and you’re done. You can test by launching your published IE website. It should now be associated with the zone you specified. You can verify in IE by pressing Alt to bring up the menu bar, then File > Properties and under Zone it will tell you the zone of the current website. Every user that launches the published IE app on your server will have the website in the zone you specified.

Yes, you can get Exchange 2003 ESM tools working with both Windows 7 x64 and x86 OSes! Microsoft does not seem to want to support Windows 7 and Exchange 2003 system management tools. They have not released ESM for Windows 7 so you have to work around it. Many companies out there are still using Exchange 2003 so I’m not sure why they don’t allow for backwards compatibility.

To get ESM for Exchange 2003 to work on BOTH Windows 7 32 bit and 64 bit OS flavors, perform the following:

1. Download and install RSAT Tools for Windows 7 (Remote Server Admin Tools) here, select x86 (x86fre_GRMRSAT_MSU.msu) or x64 (amd64fre_GRMRSATX_MSU.msu) depending on what flavor of Windows 7 you are using – http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d&displaylang=en

2. Download Exchange System Manager for Windows Vista here (ESMVISTA.EXE) but don’t install it yet (see step 3) – http://www.microsoft.com/downloads/en/details.aspx?familyid=3403d74e-8942-421b-8738-b3664559e46f&displaylang=en

3. Do a silent install of ESM. This circumvents the OS check and allows you to install ESM for Vista on Windows 7. You can do this by opening a command prompt and typing this in the directory you downloaded ESMVISTA.MSI to:

ESMVISTA.MSI /q

4. If you are using Windows 7 x86, you are done and you can open up Active Directory Users and Computers (ADUC) and you will see the Exchange tabs for your users.

5. For Windows 7 x64, it’s a little tricky. It just won’t display Exchange tabs in ADUC when you open it. It took my some trial and error for a few hours before I figured it out. You have to run an MMC snapin in 32 bit mode to get the tabs to work. You can do this by opening a run prompt and typing:

mmc /32

then adding the “Active Directory Users and Computers” snap-in (should be the 3rd option). I am thinking this is because the ESM for Vista package was not designed for x64 and some level of compatibility is missing. Evidence for this is that if you check the target for the ESM or ADUC shortcuts, you will see this which clearly shows it’s installed in the x86 Program Files folder:

C:\Program Files (x86)\Exchsrvr\bin\exchange system manager.msc
C:\Program Files (x86)\Exchsrvr\bin\users and computers.msc

Now the problem is that everytime I added the ADUC snapin in an MMC window, the text for it would disappear and I would get an error saying “MMC cannot initialize the snap-in” followed by the MMC crashing. I checked the application event log and found the following:

Faulting application name: mmc.exe, version: 6.1.7600.16385, time stamp: 0x4a5bc3f1
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b29c
Exception code: 0xc0150010
Fault offset: 0x0008454b
Faulting process id: 0x98c
Faulting application start time: 0x01cb970a650fbae3
Faulting application path: C:\Windows\SysWOW64\mmc.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: aac5fead-02fd-11e0-9946-005056b64915

So obviously a core Windows 7 x64 system file is the culprit, ntdll.dll. Luckily, there is a release candidate for Windows 7 SP1 available for download here (windows6.1-KB976932-X64.exe):

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda

I assumed that the service pack might fix whatever the issue was with ntdll.dll since it is a core system file. Turns out I was right, after installing Windows 7 SP1, I can now successfully open an MMC window in 32 bit mode and add the ADUC snapin. Now all my Exchange tabs show up in ADUC (Exchange General, E-mail Addresses, Exchange Features, & Exchange Advanced). See screenshot below:

Now I’m not advising you deploy a release candidate service pack into your environment. But for systems admins, we typically have a bit more leeway on our systems than end users so if you are under no policy restricting installing a release candidate on your workstation, then go for it. You can even install it in a VM temporarily until SP1 is released so you don’t have to jeopardize your workstation with an RC build. Let me know how it works out for you!

Always remember to sysprep when cloning a node! MSMQ (Microsoft Message Queuing) uses a registry valued called QMId located at:

HKLM\Software\Microsoft\MSMQ\Parameters\Machine Cache

which has to be unique on all your servers or it will cause all sorts of issues. Sysprepping a server generates a new SID which also generates a new QMId in the process. If you don’t do this and have multiple servers out there with the same QMId, you will see strange things like messages remaining in the outgoing queue in limbo and sometimes just disappear completely with no trace in journaling anywhere. Bottom line, don’t confuse MSMQ! It’s fragile!

Thankfully John Breakwell (MSMQ guru at Microsoft) blogged about this exact issue which made me realize what was going on in the environment I was troubleshooting. Well done John!

http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

I simply ran sysprep and resealed the clone to fix it. It automatically generated a new QMId in the process so I didn’t have to follow the exact steps John had blogged about. It was a simple mistake which can be avoided in the future by using the Guest Customization Wizard in VC to automatically sysprep when creating the clone.

BTW, you can check if your SIDs are identical on a server by using getsid.exe. Download the Windows XP Service Pack 2 Support Tools:

http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en

and use the getsid.exe tool to compare SIDs on your Windows servers. Usage syntax is here:

http://technet.microsoft.com/en-us/library/cc784314%28WS.10%29.aspx

Since I’m blogging about MSMQ, let me take a moment to plug QueueExplorer (http://www.cogin.com/mq). This is hands down the best MSMQ management software I have ever used and the developer is very open to feature requests. Give them some business and tell them Jason sent ya! Check out a screenshot of it below:

IP Address conflict? Have you narrowed the MAC down to being a VM in one of your ESX/vSphere clusters? Well use vSphere PowerCLI to figure out what device and adapter is causing the conflict.

Example, if your MAC is 005056b60b13:

Get-vm | Select Name, @{N="Network";E={$_ | Get-networkAdapter | ? {$_.macaddress -eq "00:50:56:b6:0b:13"}}} |Where {$_.Network-ne ""}

And it will output the VM name and the Network Adapter causing the conflict.

A co-worker and myself were asked to create a VMware vSphere (ESX) template for Server 2008 R2 and it’s not as easy as you might think. Over the course of a day and half and through much research and trial and error, we have come up with the perfect template for our organization. It’s a perfect base template for us but depending on where you intend to deploy it and your own organization’s requirements, you may have to edit it a bit. We intend to tweak the template even further and possibly even create separate images depending on if the VM will be deployed internally or externally. Please do comment if you have any suggestions or think we may have missed something.

Building a VMware template for Server 2008 vs. Server 2008 R2 has some differences. This blog post will cover everything we did to successfully get it working and a detailed explanation of why we chose certain settings. Big thanks to to Jeremy Waldrop and his blog post that described setting up a template for 2008 which helped us quite a bit in our research to create the perfect template for 2008 R2.

OS Used: Windows Server 2008 R2 Standard (x64) Volume License Edition

VM Hardware config:

• Single vCPU
• 4 GB RAM
• 40 GB Primary Hard Drive (for Operating System)
• 10 GB Secondary Hard Drive (for Page File
• LSI Logic SAS SCSI Controller
• VMXNet 3 Network Adapter

I know most organizations using Server 2003 have always done a 20 GB C: partition. With 2008, I suggest going to 40 GB OS drives as a standard. Server 2008 (especially x64 versions) requires more space. Out of the box 2008 R2 x64 takes up 10 GB. Also Server 2008 has a component store (c:\windows\winsxs) which is very large. This is because 2008 no longer uses i386, everything is stored locally already in this component store folder. Remember, Server 2008 and any future MS product is all about componentization!! When you install a component from this store, my understanding is that it is “projected” to the OS. So basically Windows 2008 installed components run from this component store essentially. As the system receives updates over time, expect this directory to grow even larger since it never deletes old stuff. Think of the different versions of kind of stacking on each other. I believe with each service pack there is a tool to uninstall components that are no longer necessary or superseded. So stick with a 40 GB OS partition and you should be fine for a long time. You will also notice we have a 10 GB secondary drive for a page file. We’ll get to that later in the article.

Now on to the actual build:

1. First create a new VM
   • Select Custom Configuration
   • Enter VM Name and Inventory Location
   • Select Datastore
   • Select Virtual Machine Version: 7
   • Select “Microsoft Windows Server 2008 R2 (64-bit)” as OS Version
   • # of Virtual Processors: 1
   • Amount of RAM: 4GB
   • Network
     • # of NICs: 1
     • Adapter Type: VMXNET 3
     • Select “Connect at Power On
   • SCSI Controller: LSI Logic SAS
   • Create New Virtual Disk: 40GB
   • Advanced Options: No Change
2. Now prepare the virtual hardware:
   • Edit VM Settings > Options > General Section > Uncheck “Enable logging”
   • Boot Options > Check box to force going into the BIOS on next boot
   • Power on the VM (will go directly to BIOS) > Advanced > I/O Device Configuration:
     • Disable Serial port A
     • Disable Serial port B
     • Disable Parallel port
   • Exit and Save
3. OS Installation and Configuration
   • Install Windows 2008 R2 Standard – Full Install
   • After OS install and reboot, change Administrator Password (will prompt)
   • Disconnect Windows 2008 R2 ISO and set device type to Client Device
   • Set Time Zone
   • VMware Tools Install
     • Install VMtools, choose Custom Install Type
     • Disable the “Shared Folders” drive and install Tools ** Note we are disable Shared Folder due to profile loading issues which was documented even back in ESX 3.5 and VMware Tools here on the VMare Communities forum. I have not personally had an issue leaving it enabled but just to be cautious and the fact we don’t use this feature in our organization, we have left it disabled.
     • Set time synching between the VM and ESX host
     • Reboot after Tools Install
   • Network Configuration
     • From Server Manager, select View Network Connections
     • Right click on Local Area Connection and select properties
     • Uninstall QoS Packet Scheduler and both Link-Layer Topologies (Mapper & Responder) ** We don’t do QOS at the server level, our switches do that. Link Layer is not used by us.
     • Uncheck IPv6 and close network connection screens ** We don’t use IPv6 yet so we disabled it for now
   • Server Name
     • From Server Manger select Change System Properties
     • On System Properties screen click Change on Computer Name Tab
     • Set Server Name and restart
   • Windows Updates
     • From Server Manager under Security Information, select Configure Updates
     • Select Let me choose
     • Under Important Updates, select Never check for updates, click ok
     • Start > All Programs > Windows Update > Check for updates and install all Recommended Updates
   • Enable Remote Desktop, choose “Allow connections from computers running any version of Remote Desktop” (2^nd option)
   • Disable Windows Firewall **Not best practice to disable, but my environment requires it
   • From Server Manager, select “Do not show me this console at logon” and close Server Manager
   • Taskbar Changes
     • Right click 3^rd icon from Start Button (Windows Explorer) and select “Unpin this program from taskbar”
     • Right click 2^nd icon from Start Button (Windows PowerShell) and select “Unpin this program from taskbar”
     • Right click Taskbar and choose Properties and choose Customize under Notification Area
     • Select “Turn system icons on or off”, and turn Volume Off, click Ok
   • System Performance
     • From Server Manager select Change System Properties
     • Select Advanced Tab > Settings and choose “Adjust for best performance”
   • Folder and Search Options
     • Open “Computer” > Select Organize > Choose Folder and search options
     • Under View Tab
       • Select “Show hidden files, folders and drives”
       • Uncheck “Hide extensions for known file types”
   • IE ESC
     • From Security Information Section, select Configure IE ESC
       • Change Administrators to Off and leave Users On ** My reasoning for this is the only “Users” should be service accounts on a server so leaving it On should not matter
   • Change IE Home Page to blank so you don’t get that pesky Internet Exploer Enhanced Security Configuration warning page
   • Under Computer, right click c: and select properties, uncheck “Allow files on this drive to have contents indexed in addition to file properties”
     • Apply changes to c:\ and all subfolder/files
     • Continue/Ignore on Access Denied errors
   • Power Options (from Control Panel)
     • Change option to High Performance
   • Disable Hibernation
     • Command Prompt, enter powercfg.exe –h off
   • Delete the Page file and reboot (so c:\ can be fully defragmented)
   • Run defrag
   • Page File
     • Edit VM Properties
     • Add a 2^nd hard drive (10GB) and change to SCSI (1:0)
     • Run Disk Manager and format as Z:\ drive ** We use Z: as the drive letter so it does not interfere with adding additional drives later on.
     • From Server Manager, select System Properties > Advanced > Performance Settings > Advanced > Virtual Memory Change
       • Assign 1024MB Page file to c:\
       • Assign 5120MB Page file to z:\
   • SNMP
     • Server Manager > Add Features > SNMP
     • Server Manager > Configuration > Services > SNMP > Security
       • Accepted community names – Add your community (as READ ONLY)
       • Accept SNMP Packets from these hosts – Add your hosts (remember to leave localhost in there)
4. Turn VM into a Template
   This procedure will copy the Administrator account profile into the default user profile so that all users that login or that will be created in the future will get the same profile with all the customizations you have done above. When you sysrep a server template and create a new VM from it, a new SID is generated which means a new local Administratior account is created during the sysrep procedure. This means all the customizations you have done will be wiped out above unless you copy all your settings above when you create a new VM. In the past with Server 2003 and even Server 2008, you had the “Copy To” feature to copy a user profile to another. With Server 2008 R2, Microsoft has disabled this feature. It is now done via an unattend.xml file using the “CopyProfile” node. I actually prefer this method now after doing it a few times. This procedure is detailed per the Microsoft KB article http://support.microsoft.com/kb/959753
   • Create unattend.xml in “c:\windows\system32\sysprep” folder as follows. NOTE: Do not copy and paste the text below because WordPress messes up the quotes which will lead to errors during sysprep. Please right click-save as this link and copy and paste from the txt file instead.
     

     
     <?xml version="1.0" encoding="utf-8"?> 
     <unattend xmlns="urn:schemas-microsoft-com:unattend"> 
     <settings pass="specialize"> 
     <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
     <RegisteredOrganization>Your Organization Name</RegisteredOrganization> 
     <RegisteredOwner>Your Registered Owner</RegisteredOwner> 
     <CopyProfile>true</CopyProfile> 
     </component> 
     </settings> 
     <cpi:offlineImage cpi:source="wim:f:/sources/install.wim#Windows Server 2008 R2 SERVERSTANDARD" xmlns:cpi="urn:schemas-microsoft-com:cpi" /> 
     </unattend>
     

   • At command prompt, type the following command:
     C:\windows\system32\sysprep\sysprep.exe  /generalize /unattend:unattend.xml
   • System Preparation Tool 3.14
     • Choose Enter System OOBE
     • Check Generalize button
     • Leave shutdown option as reboot
     • Click OK
   • Release the IP and turn VM into a template in Virtual Center

I hope this guide we wrote helps someone out there and saves you time. If you have any suggestions or questions, please leave a comment. I can take screenshots of any parts above you are confused on. I am also interested in knowing about more performance related customizations you guys might use we can add to your template so if you have any, please let me know.

Disasters happen and with a bit of skill and some luck, you might be able to get back into your operating system.  But you might notice a bunch of things out of place or missing if you had to do a Windows repair or use the Recovery Console to set things back to factory settings.

One of the tools I like to use is System File Checker (sfc.exe) which compares your file system against the original install disk and replaces missing or corrupt system files as needed.  Just go to a command prompt and type:

sfc /scannow

and Windows File Protection will begin scanning all your protected system files immediately.  If you get a prompt asking you to insert a disk, just cancel out and edit your registry key here:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup

and verify SourcePath is set to your CD-ROM drive with your install CD in it.  You’ll have to reboot to make sure the changes take effect.  Also you might want to verify:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\ServicePackSourcePath

is set to C:\WINDOWS\ServicePackFiles just so your service packs you have installed after installing the original OS are taken into account and not overwritten by older versions.