MED-V – Changing the Workspace Memory pre-deployment

I’ve been working on developing a MED-V workspace for my company.  It’s going to be used to run a single application, and as such, it shouldn’t need much memory.  Some of the systems the workspace will run on will have only 2GB of memory so I don’t want to be using 1GB for the workspace.  I fiddled around for a while trying to find the way to make this change before I started investigating the powershell script in the workspace directory.  If you haven’t run the Workspace Packager yet, this directory won’t exist, but you can copy the commands below into a PS1 and run them yourself.  I would run the Workspace Packager first though so you better understand the options.  In the PS1 file there are a couple of new Med-V specific commandlets used: New-MedvConfiguration,  Export-MedvConfiguration, New-MedvWorkspace, and Export-MedvWorkspace.  Here’swhat my PS1 script looks like (with any company specific info removed, of course!):

Import-module -Name “Microsoft.Medv”

$regFileInfo = New-MedvConfiguration -VmNetworkingMode “BRIDGED” -UxLogonStartEnabled “False” -UxCredentialCacheEnabled “False” -UxRedirectUrls “http://oldsite.mycompany.com” -FtsMode “Attended” -VmMultiUserEnabled “True” -FtsAddUserToAdminGroupEnabled “False” -FtsStartDialogMsg “A virtual environment is being created for application compatibility. The first time setup process can take several minutes to complete.” -FtsFailureDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsRetryDialogMsg “First time setup failed while creating a virtual environment for application compatibility.” -FtsSetComputerNameEnabled “True” -FtsComputerNameMask “v%hostname%[14]” -FtsSetRegionalSettingsEnabled “True” -FtsSetUserDataEnabled “True” -FtsSetJoinDomainEnabled “True” -FtsSetMachineObjectOUEnabled “True” -VmMemory 512 | Export-MedvConfiguration -Path “C:\Users\heaths\Documents\MyCompany XP VM\MyCompany XP VM.reg” -PassThru

if ($regFileInfo) #If the .Reg file was created, then create the workspace package

{                 New-MedvWorkspace -WorkspaceName “MyCompany XP VM” -VhdFilePath “C:\Users\heaths\AppData\Local\Microsoft\Windows Virtual PC\Virtual Machines\MyCompany XP VM.vhd” -SettingsFilePath “C:\Users\heaths\Documents\MyCompany XP VM\MyCompany XP VM.reg” -VhdRegPath “C:\Program Files\Microsoft Enterprise Desktop Virtualization\MEDV_InternetZoneHighSecurity.reg,C:\Program Files\Microsoft Enterprise Desktop Virtualization\MEDV_RestrictedBrowsingMode_Apply.reg” | Export-MedvWorkspace -Path “C:\Users\heaths\Documents\MyCompany XP VM\MyCompany XP VM.msi” -Overwrite }

OK, that’s a lot of stuff, but let’s look at what’s relevant to this post.  New-MedvConfiguration generates the object that will define your Virtual Machines properties.  Look for -VMMemory.  It’s near the end of the line, but before the Export-MedvConfiguration command.  This setting let’s me change the Virtual Machine’s memoru setting from the default 1024 MB to 512 MB.

So if you are deploying a Med-V Workspace for your company and you’d like to change the default memory setting pre-deployment, that’s how you do it!

UPDATE: I found this blog article that has great info as well.

Windows Server 2003 WDS and 64-bit Imaging

Hopefull all of you are moving rapidly to Windows Server 2008, but for the few people who have not finished updating their environment, this might help.

On servers running 2008 or 2008 R2 all of the architectures of systems being imaged was detected correctly and the x64 boot image was loaded and there was harmony in deploment land.

On servers running 2003 R2 some system would refuse to load the boot image.  After a little research it seems that this option is passed through DHCP options, but isn’t always reliable, as in my case.

On the 2003 R2 WDS server run:

wdsutil /set-server /architecturediscovery:yes

sc stop wdsserver

sc start wdsserver

Viola!  WDS will now confirm the system architecture itself.  This makes the boot process a tad longer and creates a little bit more network traffic, but in my opinion it was negligible.

MDT 2010 and Multiple DNS Namespaces

I ran into an interesting problem over the last couple of week when setting up a Windows 7 deployement infrastructure.  Some simple basics for reference:  I am using a “master” server to replicate my deployment share to roughly 40 servers at different locations using DFSR.  I have set up a domain namespace (\\company.com\deploymentshare) and I have added all of the servers to the namespace.  We have DHCP set up to deliver the DNS suffix “clients.company.com” and our servers reside in the “company.com” DNS namespace.  This seemed to work fine when I tested in our lab and at a few select sites.  When a began to move the solution into other sites and test I experienced extreme lag times in WinPE and once the MDT wizard started I was unable to connect to the deployment share.  This baffled me as it still worked when running a VM on the same Hyper-V server that hosted the WDS server and DeploymentShare.  After some snooping (and using a port span to sniff the traffic since I couldn’t load NetMon in WinPE) I realized that the WinPE client could ping the DNS namespace because if was fully qualified, but it couldn’t reach the actual server and was trying to ARP for the NetBIOS name.  As you know, normal Windows client behavior is to search the parent domain suffixes of the client.  In Windows PE this is not the case.  The solution was to add a command before the MDT scripts began to add a DNS suffix search order.  In order to make this change survive deployment share updates you have to edit the templates that come with MDT.  You can find these under C:\Program Files\Microsoft\Deployment Toolkit\Templates and they will be named Unattend_PE_x64.xml and Unattend_PE_x86.xml.  Open the files and go to the section that starts with <RunSynchronous> and change it to look like the sections below.  Update your deployment share and choose a complete rebuild and your problems are solved!

<RunSynchronous>
  <RunSynchronousCommand wcm:action="add">
    <Description>Set DNS Suffix search order</Description>
    <Order>1</Order>
    <Path>wmic nicconfig call SetDNSSuffixSearchOrder (company.com, clients.company.com)</Path>
  </RunSynchronousCommand>
  <RunSynchronousCommand wcm:action="add">
    <Description>Lite Touch PE</Description>
    <Order>2</Order>
    <Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
  </RunSynchronousCommand>
</RunSynchronous>