Chris and Daves SharePoint and Tech Blog

  This post is a follow on to my Free HyperV Monitoring Tool post where I showed you a free but limited HyperV tool for monitoring your HyperV environment, in this post I will look at Microsoft System Center Virtual Machine Manager and show some of the benefits for managing your HyperV install with this management tool.

 At Twynham we now have 2 HyperV farms one on our domain and another is for a SharePoint deployment we are hosting for the Dorset Local authority (but more about that later) for our domain SCVMM has many benefits one of the biggest being the ability to create P2V (Physical to Virtual) snapshots of our production servers SCVMM has proved an invaluable tool that we have used a great deal to help on the road to a virtualized environment.

The illustration above gives you an administration view of your HyperV deployment this report gives you a pie chart view of your hosts, Virtual Machines, Recent Jobs and library resources

I think the biggest win with SCVMM is the ability to control all of your HyperV servers from one interface for example we have been working on a customer’s site this week and they have 5 sites one with a 4 server failover cluster and 2 other sites with single HyperV servers running a number of virtual servers. Through SCVMM this brings the management of all these virtual servers into one interface simple to use interface for more details check out the SCVMM website.

Dave

Guest Post By Darren White

  Today myself and Dave where working on a customer site when the question of HyperV statistics came up, it would be good to be able to see what free memory was available on the host machine and also what memory was being used by the guest OS’s, now as has been pointed out in previous posts Dave is no expert with PowerShell but very much a newbie, whereas I am a past master (I do my best). So after searching codeplex I found the PowerShell Management Library for Hyper-V.

  After downloading and extracting please remember to unblock the zip file as illustrated below or you may encounter errors when trying to install and run the commands.

Once installed the obvious first step was to see the output of the commands, this proved to be very extensive and perfect for the job. The command we were most interested in was Get-VMSummary as illustrated below.  

As you can see the output is in list format for each item and this makes it hard to get an overview of data so the next step was to pipe it into Format-Table; Get-VMSummary | Format-Table. As illustrated below the formatted table makes it easier to read.

As you can see there is a lot of information presented that we do not need, so by using the format-table command we can specify the columns we wish to output to the screen. The main information we needed was:-

Hostname (Host), Virtual Machine Name (VMElementName), Installed Operating System (GuestOS), Number of Allocated CPU’s (CPUCount), Allocated Memory (MemoryUsage), Current State i.e. Running/Stopped (EnabledState)

Get-VMSummary | Format-Table Host, VMElementName, GuestOS, CPUCount, MemoryUsage, EnabledState

The next step was to output the information to a CSV file; this was achieved by replacing Format-Table with Select-Object and then piping this into the Export-Csv command. We also used the Sort-Object command to order the output by virtual machine name.

Get-VMSummary | Sort-Object VMElementName | Select-Object Host, VMElementName, GuestOS, CPUCount, MemoryUsage, EnabledState | Export-Csv VMInfo.csv -NoTypeInformation

The next step was to get the information from all the HyperV servers in the current domain this was achieved by using the Get-VMHost command as can be seen in the illustration below.

To continue writing our PowerShell script we included the parameter –server for the Get-VMSummary command. We passed this parameter from the Get-VMHost inside a foreach loop.

Get-VMHost | Sort-Object | foreach {
Get-VMSummary -server $_ | Sort-Object Name | Select-Object Host, VMElementName, GuestOS, CPUCount, MemoryUsage, EnabledState | Export-Csv “$_ VMInfo.csv” –NoTypeInformation
}

This will create a new CSV file for each hyperV server with the virtual machine information we have asked for.

The next step we needed to achieve was to merge the individual CSV files into one master CSV file containing the desired information on all the virtual machines in your domain. To do this we need to store to output in an array for each HyperV server instead of outputting to the CSV file. Once the array is populated we output this to the master CSV file.

$content = @();
Get-VMHost | Sort-Object | foreach {
$content += Get-VMSummary -server $_ | Sort-Object Name | Select-Object Host, VMElementName, GuestOS, CPUCount, MemoryUsage, EnabledState
}
$content | Export-Csv VMInfo.csv –NoTypeInformation

This script we saved as a PS1 file and then ran from within PowerShell, the CSV output you can see below.

This gives a great overview of all the virtual machines you have running on your HyperV server and will be a great aid when it comes to balancing the load across your HyperV servers.

A trick we used to balance the server load was, once we opened our CSV file in Excel you can use the function sumif to create the following formula, =SUMIF($A:$A,H1,$E:$E).

In our CSV column A we have the HyperV Hostname and Column E is the Virtual Machine Memory allocation. Cell H1 is next to the formula containing a HyperV hostname. We then copied this formula to the cells below for each HyperV (i.e. H2 will contain the hostname for the second HyperV and so on)

This will show the amount of Ram used on each HyperV server by the virtual machines and we hope it helps with balancing your HyperV implementation. As you can see from the illustration above our HyperV server will need balancing but that is the point of the post so we can now live migrate our virtual Servers and rerun the script until we are happy with the spread on across all of our HyperV host servers.

I hope you enjoyed this post and any questions please submit via comments on the blog or by going to http://twitter.com/whitefern and asking me there.

Darren

You may be aware of a constant debate that goes on between myself, Dave and a few others in education about running virtual environments and whether they should/could be 100% virtual of if you would need some physical domain controllers put into the mix. If you’re not familiar with the debate have a quick read of this http://sharepointineducation.com/?p=2056

So as you see, I’ve always maintained that you can have a completely virtual environment and in theory it’s all fine.

Well theory came crashing into reality this week. There was a planned power outage at school; the only flaw in the plan was that no one told us. We made it to the server room just in time to watch the UPS run out and experience the eeary sensation of a silent server room. One of the things to die was a fully virtual environment we have been playing with. The two node hyper v cluster is part of the same domain as the virtual machines that run on them. They both go off because of power and you have no domain. The theory being that you can just log in locally and start the DC, then boot 2^nd node then reboot node 1. What I hadn’t taken into account was that the cluster would not load and the DC was not available to boot from the cluster manager.

Lessons were learnt. Here they are.

If running a fully virtual environment the failover cluster and associated cluster shared volume will not start as there is no domain – this is a problem.

We fixed it by removing the cluster volume and just assigning it a drive letter on node 1 of the hyper cluster, the VHD for the domain controller could then be copied onto the local C: of node 1 and fired up via hyper-v manager. The 2^nd node could then be fired up and now having a domain to join was fine and the cluster volume was all good. The 2^nd DC was then moved to the C: of node 2. Node 1 could then be restarted and all was good from then on.

So if you go fully virtual don’t put all your domain controllers in the cluster, keep them local, one on each node as they can be started independently of shared storage or cluster.

Although I still wouldn’t be brave stupid enough to do this in production

Rule Settings in MDT 2010 

   MDT 2010 as you have seen is very customizable and you can stop some screens showing with the rules available in MDT this will cut down on the amount of input required during the operating system install. Theses inbuilt rules are quite limited so below you will find many more that you can add. 

To access the rules from the deployment workbench Right click your deployment share and choose properties the second tab (Rules) will show you the limited built in rules. 

The list of rules below when applied will only show 3 screens during the install process Computer Name

 Task Sequence Selection

 Time Zone Selection

[Settings]

Priority=Default

Properties=MyCustomProperty

 [Default]

OSInstall=YES

SkipAdminPassword=YES

SkipApplications=YES

SkipAppsOnUpgrade=YES

SkipBDDWelcome=YES

SkipBitLocker=YES

SkipCapture=YES

SkipComputerName=No

SkipComputerBackup=YES

SkipDeploymentType=YES

DeploymentType=NEWCOMPUTER

SkipDomainMembership=YES

JoinDomain=Demo

DomainAdmin=administrator

DomainAdminDomain= Demo

DomainAdminPassword=*******

SkipFinalSummary=No

SkipLocaleSelection=YES

KeyboardLocale=en-GB

UserLocale=en-GB

UILanguage=en-GB

SkipPackageDisplay=YES

SkipProductKey=YES

SkipSummary=YES

SkipTaskSequence=NO

SkipTimeZone=YES

TimeZone=085

TimeZoneName=Greenwich Standard Time

SkipUserData=Yes

I hope this article helps with your OS deployments using MDT 2010 I will try to keep the blog updated on the latest MDT improvements.

Update

On 15^th July 2010 Microsoft released update 1 for MDT 2010 I have applied this update and the good news is all still works you can download from

http://www.microsoft.com/downloads/details.aspx?familyid=3bd8561f-77ac-4400-a0c1-fe871c461a89&displaylang=en&tm

You can also find this series of post as a single pdf file see below.

MDT 2010 Setup Step by Step

Windows Deployment services PXE boot image

  One of the steps at the beginning of this article was to setup Windows Deployment Services we will now use this to deploy a PXE boot image. From the Start Menu | Administration Tools select Windows Deployment Services once open right click on boot images and select ‘Add Boot Image’

The boot images are stored in your deployment share and are found in the boot folder I will select the LiteTouchPE_x86.wim file for this demo

The final step of this part is to enable multicast this is achieved by going back to the MDT workbench and right click on the deployment share and choose properties on the general tab and tick enable multicast from the general page.

Creating a Task sequence

  The final part in configuring MDT 2010 is to create a task sequence this will enable you to deploy your chosen operating systems to your client workstations.

 The first step is to open the deployment workbench and right click on the task sequence node and choose “New Task Sequence”

The first screen you will see is the general settings enter a Task Sequence ID and a Task sequence name you can optionally enter a description

The next screen asks which template to use I will leave this at the default setting Standard client task sequence

The next screen asks you to choose your OS earlier in the article I set up a Windows 7 OS so this is displayed here

The next screen asks you to specify a product key this give you three options do not specify a product key is what I will choose as we use a KMS server for key management

The next screen asks for your OS setting Full name, Organization and IE home page

The next screen asks for a local admin password you can let the user enter their own or specify a password yourself I would always set a password otherwise you could end up in a situation where every workstation has an individual password and this situation would be unmanageable.

Next you will see a summary screen giving a breakdown of all the information in your new task sequence

Once you click next your task sequence will be created and a final confirmation screen will be shown

Finally as I have said previously update the deployment share from the deployment workbench this is always a good habit to get into after every change you make.

In the next and final part of this series we will look at MDT Rules.

Dave

Adding an application to your MDT installation

The next thing we will do is add Office 2010 to the base image this is not a necessary step at the moment so if you deploy applications using a 3rd party tool you can skip this step. Open the Deployment workbench and the MDT Deployment Share section and right click on the applications sub section and choose “New Application”

This will launch the new application wizard this will give you three options

Application with source files

Application without source files or elsewhere on the network

Application Bundle

On the next screen fill in the Publisher details, Application name, Version and Language the only mandatory field is application name

The next screen asks you to choose the location of the source files I will be using the Office 2010 DVD for this article

The next screen will ask for the destination location in your MDT deployment I will leave this at the default setting.

The next screen asks for the command line to kick off the install you can use command line arguments in this but again I will leave it as default and customize later.

Next you will see a summary screen and when you click next all the source files will be copied to your deployment.

After the copy process click finish your application is now ready to deploy with your image.

Customizing your application

   From the deployment workbench click on application and right click on your newly created package and choose properties

From this screen we will see 4 tabs including an office products tab as illustrated below.

The part we are going to focus on is the “Office Customization Tool” button you can on the office tab enter the product key and enter basic information but we will look more closely at the advanced customization available.

Office Customization Tool

  When you click on the Office Customization Tool button an information box will pop up informing you that the MSP file created will need to be stored in the updates folder so that setup can find it during the office install.

Once Ok is click you will see the screen illustrated below

Highlight the product and click OK this will give you access to the advanced customization

This interface and options available would require a booklet of its own but you can find more information at http://technet.microsoft.com/en-us/library/cc179097.aspx  

  Once you have finished your customization close the tool and update the deployment share from the workbench this is always good practice after any changes.

Adding a Base Image to MDT 2010

 The next step is now to add a base image to your MDT deployment.

Expand the deployment shares and right click Operating Systems and select ‘Import Operating System’

I will choose the Full set of source files option and for this I will need the windows 7 DVD so click next

Choose the path to your source files and click next

Select a destination directory name I will stick with the defaults for this article you will then be presented with a summary screen check to make sure all is ok and then click next this will take you to a progress screen and once the import is completed click finish.

The next step is to update the right clicking on MDT Deployment shares and choose ‘Update Deployment Share’

Select completely regenerate the boot images this is always good practice each time you make any changes to your MDT setup

In the next part in the series i will show you how to add applications to your MDT deployment

This post is a continuation in the series on MDT part 1 can be found at http://www.sharepointedutech.com/2010/07/07/mdt-2010-setup-step-by-step-part-1/

 Installing the Windows® Automated Installation Kit (AIK) for Windows® 7

   MDT 2010 uses the Windows 7 automated installation kit which can be down loaded from the Microsoft site here so before we continue I will install and configure, the download for AIK is an ISO file you can at this point burn to a DVD or unpack the ISO file and run setup.

Click on Windows AIK setup from the list on the left and all I did to complete the installation of AIK is follow the prompts and accept all the default values.

 Install Microsoft Deployment Toolkit 2010

  The next step is to download from here the installation files for MDT 2010 on this site you will find install files for 64bit and also 32bit installs as well various read me files to help you get the most out of MDT 2010.

Again with this install I will accept all the default values as I go through the install. After the install is completed you will have a new start menu item called Microsoft Deployment Toolkit we will now continue the configuration by clicking on deployment workbench.

Configure The Deployment Shares For MDT 2010

 Through this part of the post I will show how to configure the images you require for your operating system deployments I will be using windows 7 for this but you could use windows vista or XP.

You now need to create a deployment share this is completed by right clicking deployment share in the MMC and selecting ‘new deployment share’

I will store all my images on the E data drive I created earlier for my server setup

By default the system will create the share as a hidden share (With a $ symbol at the end) I will leave this as the setting to use

The next screen asks for a descriptive name I will accept the default setting

The next screen asks if an image should be captured if you are planning on using MDT to capture the image leave this ticked

The next screen asks if you should allow users to set the local admin password I would recommend leaving this unticked as you could end up not knowing the local admin password on any of your computers and potentially every machine having a unique admin password (not sure how you could manage that situation)

The next screen asks should the user be prompted for a product key this can be useful but we use a KMS server (Maybe another post) so we do not require this so I will leave it unticked.

Next you will see the summary screen check all the settings and click next

By Default the permissions setup on the deployment share are –

The next post i will include information on adding a base image

On the 8^th July 2010 I will be giving a presentation to a group of Network managers from Essex on how we deployed Windows 7 in August 2009 and covering some of the issues that we had. At that time we used ghost to deploy but now we are using Microsoft Deployment Toolkit so I thought I would share with you over the next few post how to setup MDT and start to deploy your operating systems and applications with this great free tool.

None of this would have been possible without the hours of research and trial and error put in by Neil Hodgkinson my assistant network manager who has perfected the use and deployment of MDT down to a fine art.

Installing MDT

 The first step is to add the Windows Deployment Services role from server manager

Leave both role services ticked please be aware of the prerequisites required to run WDS i.e. Active Directory, DNS and DHCP these do not need to be installed on this server but available on the domain  

Configuration of MDT

 Once the role is installed the next step is the configuration of the server, from server manager click on the newly installed WDS Role if you then click on the servers item in the view you will see that further configuration is required on the server.

Right click on the server name and choose ‘Configure Server’

You will then be presented with an information screen outlining the prerequisites required to run WDS as I stated earlier

The only additional requirement is that the server has an NTFS partition to store the images on

For this series of posts I have configured this virtual machine with a 40GB Data partition as you can see from the screenshot above it does recommend that the images are not stored on the system partition.

The next screen is the PXE Server Initial Settings screen here you are presented with 3 options

For this series I will select ‘Respond to all computers (Known and Unknown)’ with this option selected you are also presented with a further tick box that allows you to configure an option that requires admin approval to unknown client computers through the pending node snap in.

 I will un-tick add images to the server now as we will be using MDT 2010 for our image creation and management. The screenshot below shows the WDS snapin as represented in server manager the next step is the MDT 2010 setup.

In the next post in this seies i will show you how to install and configure AIK

 As I have said I previous posts myself and Alan Richards have been giving a series of presentations on SharePoint 2010 and virtualization, this is an ever evolving presentation thanks to questions we get asked and one of those questions was the licencing model for HyperV so I thought that through this post I would explain the licencing of your Guest Windows servers OS’s on HyperV and the different licencing options you are presented with depending on the host version of Windows that you choose to run your HyperV environment on.

 As I stated in a previous post on licencing SharePoint 2010 for education in the UK the subject of Microsoft licencing is always a lively discussion and so it proved with that particular post but from the research I have done I think the licencing model for HyperV is pretty cut and dried (Well let’s hope so.)

Windows Server 2008 Standard

 This version provides you with a single free licence for your HyperV guest windows server operating system.

Windows Server 2008 Enterprise Edition

 The enterprise edition of Server 2008 allows you to run 4 guest Windows server instances free from additional licence costs.

Windows Server 2008 Datacentre Edition

 With the Datacentre version the licencing model for the host is slightly different in as much as this version is licenced per processor (Not cores but physical platters) so a single quad core processor would only require 1 Datacentre licence but does provide the best value for large HyperV environments, as this version of Windows server provides you with unlimited licences for your guest Windows server operating systems. The Datacentre version was at one point only available as an OEM product when purchased with hardware but that changed in October 2006 and is now available through your normal licencing channel.

 I have provided below a simple table to help with your decisions on which version of Windows server to run in your host HyperV setup.