Welcome to TechNet Blogs Sign in | Join | Help

In some instances, more than one product can have a cmdlet with the same name. This blog post will show you how to specify a VMM cmdlet if another product has a cmdlet with the same name:

 

If two Windows PowerShell modules contain cmdlets with the same name, use the following format to specify the one you want:

 

<Module>\<Cmdlet>

 A typical output from PowerShell is the following if you don't fully differentiate between the cmdlets.

<<

PS D:\Users\mlmich> get-help get-job

Name                              Category  Synopsis
----                              --------  --------
Get-Job                           Cmdlet    Gets Virtual Machine Manager job objects on the Virtual Machine Manager ...
Get-Job                           Cmdlet    Gets Windows PowerShell background jobs that are running in the current ...

>>

Note: The same syntax also works if two Windows PowerShell snap-ins contain cmdlets with the same name:

To fix this and get the help for the cmdlet you want for example, use the following approach. 

Get-Help Microsoft.PowerShell.Core\Get-Job -detailed

Get-Help Microsoft.SystemCenter.VirtualMachineManager\Get-Job -detailed

Even though VMM does not officially support the Windows PowerShell Remoting feature of PowerShell v2, you can get this to work by following the guidelines in this blog post. Officially, to execute the VMM cmdlets you need to install the VMM Administrator Console on all client computers that need to use the cmdlets, but by following the steps in this post, you can run VMM cmdlets on a machine that has no VMM components installed at all!

To illustrate how to use PowerShell remoting with the VMM cmdlets, i have set up a simple architecture that is also illustrated in the picture below. I will be using the computer names in that picture throughout this blog post. Make sure that you are using Windows PowerShell v2 on both simpleclient and adminconsole computers. PowerShell v2 is installed by default on Win2k8 R2 computers.

To get started, first enable WinRm on the the computer simpleclient and the computer adminconsole. PowerShell remoting depends on WinRM. To enable WinRm on each of the two computers, run "winrm quickconfig" from a command prompt to create a WinRM listener on HTTP://* and to add the necessary firewall exceptions for WinRM.

Next, because your credentials need to double-hop from the simpleclient to the adminconsole and then to the vmmserver, we need to use CredSSP. CredSSP can be used to delegate the credentials to the remote computer so that the VMM server can authenticate the cmdlet requests. Failure to enable CredSSP on the simpleclient and the adminconsole computers will most likely result in this error when you try to get a connection to the VMM server using the get-vmmserver cmdlet.

<<
You cannot access Virtual Machine Manager server vmmserver.contoso.com.
Contact the Virtual Machine Manager administrator to verify that your account is a member of a valid user role and then
 try the operation again.
    + CategoryInfo          :
    + FullyQualifiedErrorId : 1604,Microsoft.SystemCenter.VirtualMachineManager.Cmdlets.ConnectServerCmdlet
>>

To enable CredSSP, from an elevated Windows PowerShell Window do the following:

-On the simpleclient computer, execute: "Enable-WSManCredSSP -Role client -DelegateComputer adminconsole.contoso.com"

-On the adminconsole computer, execute: "Enable-WSManCredSSP -Role server"

You can read more about CredSSP and the double-hop issue at http://blogs.msdn.com/clustering/archive/2009/06/25/9803001.aspx and at http://blogs.msdn.com/powershell/archive/2008/06/05/credssp-for-second-hop-remoting-part-i-domain-account.aspx.

Now that CredSSP and WinRM are configured, open a Windows PowerShell window on the simpleclient computer and execute the following cmdlets. This example shows you how to execute VMM cmdlets using the SSH/Telnet experience (meaning everything happens on the remote computer adminconsole).

<<

# get credentials that are also a VMM Administrator
$cred = get-credential

# show the computer name we are on right now, namely simpleclient
$env:COMPUTERNAME

# create a PS session using CredSSP to the adminconsole computer
New-PSSession adminconsole.contoso.com -Authentication CredSSP -credential $cred | Enter-PSSession

# show the computer name we are on right now. It should have changed to adminconsole
$env:COMPUTERNAME

# add the VMM Windows PowerShell snapin
add-pssnapin Microsoft.SystemCenter.VirtualMachineManager

# start executing VMM cmdlets. First get a connection to the VMM server and then
# get a listing of all VMs in the system and some of their properties
get-vmmserver vmmserver.contoso.com
get-vm | select name, id, status, hostname | format-list
>>

 Now, the following example will show you how you can call the VMM cmdlets locally on the simpleclient computer without any binaries being installed on that computer :) (the no-bits on the client scenario is super powerful)

<<

# get credentials that are also a VMM Administrator
$cred = get-credential

# show the computer name we are on right now, namely simpleclient
$env:COMPUTERNAME

# create a new session to the target machine where the VMM Administrator Console (the snapin/module) is installed
$session = New-PSSession adminconsole.contoso.com -Authentication CredSSP -credential $cred

# load the VMM cmdlets in the PS Session
Invoke-command $session {add-pssnapin Microsoft.SystemCenter.VirtualMachineManager}

# import the get-vmmserver and the get-vm cmdlets from the remote pssession into the current session
$vmmcmdletstoimport = @("get-vmmserver", "get-vm")
Import-PSSession $session –CommandName $vmmcmdletstoimport

# now you can call these VMM cmdlets locally as if those commands are present on the client machine
# this allows for mixing of remote and imported cmdlets

# prove that we are still on the simpleclient computer
$env:COMPUTERNAME

# start executing VMM cmdlets. First get a connection to the VMM server and then
# get a listing of all VMs in the system and some of their properties
get-vmmserver vmmserver.contoso.com
get-vm | select name, id, status, hostname | format-list

# Magic :)
>>

Once you are done, you can disable CredSSP using the following commands:

-"Disable-WSManCredSSP -Role client" on the simpleclient computer

-"Disable-WSManCredSSP -Role server" on the adminconsole computer

In this blog post, I will talk about what is the proper way to share ISO files with VMM and Hyper-V when the ISO files reside in the VMM library (i.e. a file server share).

First, you need to follow Jose Barreto's blog post on how to properly enable constrained delegation on the Hyper-V servers. You need to follow these steps for every Hyper-V host on which you want to create a Virtual Machine and attach a shared ISO. Additionally, these steps need to be followed for every library server that will host ISO files that are going to be linked from Virtual Machines.

http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx

Once constrained delegation is set up, ensure that the VMM service's Log On account (the VMM service is called Virtual Machine Manager and it runs only on the VMM server component)  is a domain user and not local system. If you have already installed VMM using the Local System account, you can uninstall VMM using the "Retain Data" option. This will uninstall VMM but will keep the database intact so that there is no loss of data. Then go ahead and reinstall VMM, pointing setup to the same database you used earlier. On the Installation Settings page of setup, make sure to select a Domain account for running the VMM service. Once everything is installed, open the Administrator Console and navigate to the Administration | Managed Computers view. If there are any hosts in an Access Denied state, select them and execute the reassociate action. This will make the environment healthy and functioning again.

 Once the Log On account for the VMM service is properly set up to a domain account, shared ISOs will work. Simply click on the Virtual Machine properties, go to the hardware tab and attach a shared ISO.

Shared ISO in VMM 2008 R2

Check out the team blog site of the new Windows 7 features of Windows Virtual PC and Windows XP Mode here

http://blogs.technet.com/windows_vpc/

 

hey everyone, today i have a guest poster on my blog. Laurie McKnight from the VMM team will illustrate some of the advanced functionality you can achieve with Script Functions, Script Modules and Binary Modules in PowerShell.

How to save a PS 2.0 advanced function

 

CAUTION: Methods that work but are **NOT** recommended are included but struck out.

                 These method are included to clarify that using that method is not appropriate or not recommended.

 

To distinguish one type of advanced function from others based on file type, the following examples use these (arbitrary) naming conventions:

  • ScriptFunction1.ps1 [referred to in text below as a "script-function"]
  • ScriptModule1.psm1 [referred to in text below as a "script-module"]
  • BinaryModule1.dll [referred to in text below as a "binary-module"]

 

Type an advanced function directly into a PS Profile file

Location / Action

PERSONAL PATH and PROFILE:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Profile.ps1

 

Type the advanced function directly into Profile.ps1 (your personal profile file).

 

ALL USERS PATH and PROFILE:

<C>:\Windows\System32\WindowsPowerShell\V1.0\Microsoft.PowerShell_profile.ps1

 

NOTE: PowerShell 2.0 will still use "V1.0" in this path.

 

Type the advanced function directly into the Microsoft.PowerShell_profile.ps1 (all users profile file).

 

 

Call an advanced function (.ps1 or .psm1) from within a PS Profile file

Location / Action

PERSONAL PATH and PROFILE + .ps1 FILE:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Profile.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\ScriptFunction1.ps1

 

  • 1. Save the advanced function as a script (a .ps1 file) in the same folder as your personal Profile.ps1 file.
  • 2. Add the following line inside Profile.ps1:

 

. .\ScriptFunction.ps1

 

NOTE: When the script is in the same directory as the profile file, notice that the syntax to use is "dot space dot." The dot followed by a space followed by a second dot and then the script/function name calls the script/function, that is, causes the script/function to act as if the entire advanced function had been typed into the profile file. When you use "dot sourcing," everything you define in the .ps1 file runs in the same shared session state; therefore, variables, functions, etc, are visible globally.

 

Alternatively, you "dot source" a script by using a dot, then a space, then the complete path as follows:

 

. C:\MyScripts\MyAdvFunc1.ps1

 

PERSONAL PATH and PROFILE + psm1 FILE -- OK only for informal testing; this is **NOT** the recommended way to store modules:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Profile.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\ScriptModule1.psm1

 

  • 1. Save the advanced function as a module (a .psm1 file) in the same folder as your personal Profile.ps1.
  • 2. Import the advanced function by adding the following line inside Profile.ps1:

Import-Module ScriptModule1.psm1

 

NOTE: You might assume that the Import-Module command calls the module/function, that is, causes the module/function to act as if the entire module/function had been typed into the profile file. However, modules have their own session state (part of memory that stores things such as values of variables, etc.) and therefore behave differently from the dot sourcing of .ps1 files.

In the module case, only those things that you export from the module are visible globally; everything else is private to the module's session state (this is like a C# class). You specify what to export using Export-ModuleMember cmdlet in your .psm1 file.

Example: At the end of a .psm1 file named NewDiffDiskVMModlue.psm1 that defines a function named New-DiffVM, after the final "}", you can add the following command:

Export-ModuleMember -Function New-DiffVM

In the absence of a call to Export-ModuleMember, all commands (functions + cmdlets) are exported by default (i.e. public) and variables and aliases are not exported (i.e. kept private to the module).

 

NOTE: The Import-Module cmdlet looks for files in the following order:

  • a. ModuleName.psd1
  • b. ModuleName.psm1
  • c. ModuleName.dll

 

ALL USERS PATH - CAUTION: Not recommended -- not secure!

<C>:\Windows\System32\WindowsPowerShell\V1.0\Microsoft.PowerShell_profile.ps1

 

Do **not** save the advanced function as a script file (.ps1 file) or as a module file (.psm1 file) in the same folder as the all users Microsoft.PowerShell_profile.ps1 and then call it from within the profile file.

 

This does work if, for example, you want to openly share scripts within an organization, but is a potential security risk if sensitive processes are contained in the scripts.

 

 

Recommended method for individual advanced functions:

Save an advanced function as a script-module (.psm1) or binary-module (.dll) in a sub-folder under Modules, & then import the module

REQUIRED:

  • (1) Add a subfolder under the Modules folder.
  • (2) Use the same name for the subfolder and for the (primary) module file.
  • (3) Use a separate folder for each module.

OPTIONAL:

  • A module manifest (.psd1 file) is optional but strongly recommended for complex modules, especially if more than one .psm1 file (or more than one DLL file) exists.
  • If you do include a .psd1 file, its name must be the same as the folder and module file names.

DEFAULT MODULE PATHS:

  • PS looks for modules in the default directories if you do not specify the full path to a module. The default value of $env:PSModulePath is:

$home\Documents\WindowsPowerShell\Modules; $pshome\Modules

  • You can customize the module path by using the PSModulePath environment variable. For more information, type Get-Help about_Environment_Variables.

Location / Action

PERSONAL PATH + .psm1 MODULE:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\ScriptModule1.psm1 [ REQUIRED ]

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\ScriptModule1.psd1  [ OPTIONAL ]

 

  • 1. Save ScriptModule1.psm1 in your private path in a subfolder also named ScriptModule1.
  • 2. Next, import the module:

Import-Module ScriptModule1

 

PERSONAL PATH + .dll MODULE:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\BinaryModule1\BinaryModule1.dll      [ REQUIRED ]

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\BinaryModule1\BinaryModule1.psd1 [ OPTIONAL ]

 

  • 1. Save BinaryModule1.dll in your private path in a subfolder also named BinaryModule1.
  • 2. Next, import the module:

Import-Module BinaryModule1

 

ALL USERS PATH + .psm1 MODULE -- Do NOT put your module here unless it is a Windows component (Active Directory, IIS BITS, etc)

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\ScriptModule1.psm1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\ScriptModule.psd1  

 

  • 1. Save ScriptModule1.psm1 in the all users path in a subfolder also named ScriptModule1.
  • 2. Next, import the module:

Import-Module ScriptModule1

 

IF YOUR MODULE IS **NOT** A WINDOWS COMPONENT, USE ONE OF THESE METHODS INSTEAD:

  • Put user modules in <C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\
  • Put product specific modules under Program Files and add that path to the PSModulePath environment variable. See

http://msdn.microsoft.com/en-us/library/dd878350(VS.85).aspx

 

ALL USERS PATH + .dll MODULE -- Do NOT put your module here unless it is a Windows component (Active Directory, IIS BITS, etc)

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\BinaryModule1\BinaryModule1.dll      

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\BinaryModule1\BinaryModule.psd1    

 

  • 1. Save BinaryModule1.dll in the all users path in a subfolder also named BinaryModule1.
  • 2. Next, import the module:

Import-Module BinaryModule1

 

IF YOUR MODULE IS **NOT** A WINDOWS COMPONENT, USE ONE OF THESE METHODS INSTEAD:

  • Put user modules in <C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\.
  • Put product specific modules under Program Files and add that path to the PSModulePath environment variable. See

http://msdn.microsoft.com/en-us/library/dd878350(VS.85).aspx.

 

 

Recommended method for a set of advanced functions:

Save a set of advanced functions in a sub-folder under Modules; create a script-module to call the set of functions; & then import the module:

NOTE: The information on this page is **not** about product specific modules.

           A product specific module is saved under Program Files, and its path is added to the PSModulePath environment variable. See:

           http://msdn.microsoft.com/en-us/library/dd878350(VS.85).aspx

Location / Action

PERSONAL PATH + FUNCTIONS + .psm1 MODULE:

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\ScriptModule1.psm1 [REQUIRED]

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\ScriptModule1.psd1  [ OPTIONAL ]

 

NOTE: In this case, it is the .psm1 file name (not the .ps1 file names) that matches the folder name.

 

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\Script-Function1.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\Script-Function2.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\Script-Function3.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\Script-Function4.ps1

<C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\ScriptModule1\Script-Function5.ps1

 

  • 1. Create a sub-folder under Modules and an (empty, at first) script-module file (.psm1 file with the same name.
  • 2. Save a set of advanced functions as script-function files (.ps1 files) in the same sub-folder.
  • 3. Open the script-module file (.psm1) file and call the script-function files (aka "dot source the script-function files") like this:

 

. $psSScriptRoot\ScriptFunction1.ps1

. $psSScriptRoot\ScriptFunction2.ps1

. $psSScriptRoot\ScriptFunction3.ps1

. $psSScriptRoot\ScriptFunction4.ps1

. $psSScriptRoot\ScriptFunction5.ps1

 

NOTE: Each entry must be on a new line.

 

  • 4. Next, import the module:

Import-Module ScriptModule1

 

NOTE: This command imports the script-module file (.psm1 file) -AND- all of the script-function files (.ps1 files) listed in the script-module file, all in one step.

 

LATER:

If you add another script-function to this sub-folder later, use the following command to reload the module with the new file:

Import-Module ScriptModule1 -Force

 

ALL USERS PATH + FUNCTIONS + .psm1 MODULE -- Do NOT put your module here unless it is a Windows component (Active Directory, IIS BITS, etc)

 

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\ScriptModule1.psm1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\BinaryModule1\ScriptModule.psd1    

 

NOTE: In this case, it is the .psm1 file name (not the .ps1 file names) that matches the folder name.

 

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\Script-Function1.ps1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\Script-Function2.ps1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\Script-Function3.ps1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\Script-Function4.ps1

<C>:\Windows\System32\WindowsPowerShell\V1.0\Modules\ScriptModule1\Script-Function5.ps1

 

  • 1. Create a sub-folder under Modules and an (empty, at first) script-module file (.psm1 file with the same name.
  • 2. Save a set of advanced functions as script-function files (.ps1 files) in the same sub-folder.
  • 3. Open the script-module file (.psm1) file and call the script-function files (aka "dot source the script-function files") like this:

 

. $psSScriptRoot\ScriptFunction1.ps1

. $psSScriptRoot\ScriptFunction2.ps1

. $psSScriptRoot\ScriptFunction3.ps1

. $psSScriptRoot\ScriptFunction4.ps1

. $psSScriptRoot\ScriptFunction5.ps1

 

NOTE: Each entry must be on a new line.

 

  • 4. Next, import the module:

Import-Module ScriptModule1

 

NOTE: This command imports the script-module file (.psm1 file) -AND- all of the script-function files (.ps1 files) listed in the script-module file, all in one step.

 

LATER:

If you add another script-function to this sub-folder later, use the following command to reload the module with the new file:

Import-Module ScriptModule1 -Force

 

IF YOUR MODULE IS **NOT** A WINDOWS COMPONENT, USE ONE OF THESE METHODS INSTEAD:

  • Put user modules in <C>:\Users\<YourAlias>\Documents\WindowsPowerShell\Modules\.
  • Put product specific modules under Program Files and add that path to the PSModulePath environment variable. See

http://msdn.microsoft.com/en-us/library/dd878350(VS.85).aspx.

 

For more information, type:

  • Get-Help about_Scripts
  • Get-Help about_Scopes
  • Get-Help about_Modules
  • Get-Help about_Profiles
  • Get-Help about_Functions
  • Get-Help about_Functions_Advanced
  • Get-Help about_Functions_Advanced_Methods
  • Get-Help about_Functions_Advanced_Parameters
  • Get-Help about_Functions_CmdletBindingAttribute

 

Even though VMM 2008 R2 (beta or RC) does not officially support VMware vSphere/VI4, we have a few customers that have gotten some of the functionality to work.

However, one of the issues that can arise is a failure to find paths in ESX storage. Typically, a VM refresh (refresh-vm cmdlet) might fail with error 2903 - VMM would not locate the specified file [datastoreXXX]\...\...vmdk on the <vmware server name>.

In some cases of creating a new Virtual Machine on an ESX server, the VMM Job could fail with error VMTargetPathNotFound (617) - Virtual Machine Manager cannot find or cannot access the location [storageXX (XXX)]\ specified for the virtual machine.

To correct these issues, a workaround exists. Simply restart the VirtualCenter service which will refresh the datastore and allow these paths to be found by VMM.

Stay tuned for updates on the supportability of vSphere on the SCVMM team blog.

hey guys,

If you are wondering when VMM 2008 R2 will release, this latest blog post by Rakesh will give you the inside track.

http://blogs.technet.com/rakeshm/archive/2009/07/13/scvmm-2008-r2-release-date-information.aspx

cheers.

Today, if you are using VMM, you can quickly and easily find out if your VM has the integration components installed by using this simple PowerShell script.

<<

PS D:\Windows\system32> get-vm | select name, hostname, hasvmadditions, vmaddition | format-list


Name           : vmonmlmich
HostName       : car-1.contoso.com
HasVMAdditions : False
VMAddition     : Not Detected

 

Name           : win2k8r2
HostName       : AMUNRA.contoso.com
HasVMAdditions : True
VMAddition     : Detected
>>

The problem is that VMM does not give you the version information for the Integration Components in Hyper-V. if you would like to get that data, you need to use the Msvm_KvpExchangeDataItem property. Below is a script and its output that gives you all that data for all Running VMs with Integration Components installed in Hyper-V.

<<

Option Explicit

Dim WMIService
Dim KvpComponents
Dim VMList
Dim VM
Dim item
Dim component
Dim xml
Dim nodeValue
Dim nodeName

'Create the XML component
Set xml = createObject("MSXML2.DOMDOCUMENT.3.0")


'Get instance of 'virtualization' WMI service on the local computer
Set WMIService = GetObject("winmgmts:\\.\root\virtualization")

'Get all the MSVM_ComputerSystem object
Set VMList = WMIService.ExecQuery("SELECT * FROM Msvm_ComputerSystem")   
For Each VM In VMList  
 if VM.Caption = "Virtual Machine" then      
 WScript.Echo "========================================"      
 WScript.Echo "VM Name: " & VM.ElementName      
 WScript.Echo "VM GUID: " & VM.Name
 WScript.Echo "VM State: " & VM.EnabledState   
 
 if VM.EnabledState <> 2 then
  Wscript.Echo "VM is not in a running state, so no KVPs can be exchanged"  
 end if

 ' Get the list of KvpComponents
 Set KvpComponents = WMIService.ExecQuery("SELECT * FROM Msvm_KvpExchangeComponent") '.ItemIndex(0)

 For Each component in KvpComponents

  ' ensure that we are displaying the correct settings for the VM based on its instance ID/Name
  If UCase(component.SystemName) = UCase(VM.Name) then

   Dim GuestItems
    GuestItems = component.GuestIntrinsicExchangeItems
 
   ' Now enumerate the Msvm_KvpExchangeDataItem's that are in XML format
   For Each item In GuestItems

  xml.async = false
  xml.resolveExternals = false
  xml.validateOnParse = false
  xml.loadXML item

   If xml.parseError.errorCode Then
         Wscript.Echo "--> Xml Document Parse Error: " & vbcrlf & _
                     " Reason = "  & xml.parseError.reason & vbcrlf & _
                     " Line = "    & xml.parseError.line & vbcrlf & _
                     " linePos = " & xml.parseError.linePos & vbcrlf & _
                    " srcText = " & xml.parseError.srcText & vbcrlf & _
                    " ErrorCode = " & xml.parseError.ErrorCode & vbcrlf
         'WScript.quit
   Else
   xml.setProperty "SelectionLanguage", "XPath"
   set nodeName = xml.selectSingleNode("//INSTANCE/PROPERTY[@NAME='Name']")
   set nodeValue = xml.selectSingleNode("//INSTANCE/PROPERTY[@NAME='Data']")
   Wscript.Echo nodeName.Text & " --> " & nodeValue.Text
  End If

   Next
  End If
 Next

 end if
Next
>>

 

Here is some example output as well. The Integration components version is the IntegrationServicesVersion property:

<<

========================================
VM Name: win2k8r2
VM GUID: 1D157259-F91F-4C61-8A1E-72F2C5BC112D
VM State: 2
FullyQualifiedDomainName --> MLMICH-WIN2K8-1.contoso.com
OSName --> Windows Server 2008 R2 Enterprise
OSVersion --> 6.1.7056
CSDVersion -->
OSMajorVersion --> 6
OSMinorVersion --> 1
OSBuildNumber --> 7056
OSPlatformId --> 2
ServicePackMajor --> 0
ServicePackMinor --> 0
SuiteMask --> 274
ProductType --> 3
OSEditionId --> 10
ProcessorArchitecture --> 9
IntegrationServicesVersion --> 6.1.7056.0
NetworkAddressIPv4 --> 172.30.181.72
NetworkAddressIPv6 --> 2001:4898:2a:3:8531:2f57:144c:3ce8;fe80::8531:2f57:144c:3ce8%14;2001:4898:0:fff:0:5efe:172.30.181.72;fe80::5efe:172.30.181.72%15
RDPAddressIPv4 --> 172.30.181.72
RDPAddressIPv6 --> 2001:4898:2a:3:8531:2f57:144c:3ce8;fe80::8531:2f57:144c:3ce8%14;2001:4898:0:fff:0:5efe:172.30.181.72;fe80::5efe:172.30.181.72%15
========================================

>>

hi all,

today the VMM team released VMM 2008 R2 Release Candidate. You can read all about it here. http://blogs.technet.com/scvmm/archive/2009/06/06/scvmm-2008-r2-rc-public-release-available-now.aspx

Cheers.

I received my brand new Dell Latitude E4300 laptop today and I wanted to make sure i could boot both Windows 7 and Windows Server 2008 R2 on it. Here is how virtualization came in handy. Instead of partitioning my laptop using two partitions (one for each OS) and wasting space, i created a single partition on the C:\ drive that encompasses the entire solid state disk (120GB).

On the primary partition, i installed Windows 7 enterprise RC build (7100). Once that was installed and everything worked, I downloaded a sysprep-ed VHD of Win2k8 R2 RC (build 7100) and put the VHD on the c:\ drive. I then followed the instructions as outlined on this blog post by Aviraj (http://blogs.technet.com/aviraj/archive/2009/01/18/windows-7-boot-from-vhd-first-impression-part-2.aspx). This is utilizing a new feature of Windows 7 and Windows Server 2008 R2 called "boot-from-vhd". What this feature allows you to do is to create a VHD file on your operating system and then modify the boot entries so that you can boot into it, essentially creating a multi-boot environment on your PC. Read more about boot-from-vhd here: http://edge.technet.com/Media/Windows-7-Boot-from-VHD/

Once I booted into Win2k8 R2 enterprise, I made that a domain controller, enabled Hyper-V on it, and installed VMM. Now i have a laptop that i can use daily for my work using Windows 7 and I can always show off VMM and its latest features by booting into the VHD. It might be necessary on the Win2k8 R2 partition to enable the boot property for the hypervisor to auto-start. use this command for that: "bcdedit /set hypervisorlaunchtype auto"

This also means I am not wasting any space since the VHD file will grow as needed on my C:\ partition. If i want to take any other VMs on me to a customer site, I can always copy them to the C:\ drive and reference them when i boot inside the VHD. This works perfectly.

In line with the Rapid Provisioning feature that i mentioned in my previous blog post, Vishwa, a PM from our team, just posted a comprehensive list of new features of VMM 2008 R2.

Check it out here:http://blogs.technet.com/scvmm/archive/2009/05/11/scvmm-r2-rc-features.aspx

 

At MMS 2009, our team announced a new feature of VMM 2008 R2 called Rapid Provisioning. This feature is not available in VMM 2008 R2 beta, but it will be available in the upcoming release candidate and in the RTM version.

This feature was implemented in response to customers requests. In VMM 2008, the only way to deploy a new virtual machine is to copy the VHD from the library to the host over the network using BITS. Depending on the size of VHD and the available bandwidth, this could take several minutes or even hours. We heard from a lot of customers that they have sophisticated SAN technologies that enables them to clone a LUN which contains the VHD and present it to the host. However, customers still want to leverage VMM’s template capabilities with OS customization and IC installation. So they basically wanted new-VM without the network copy which is exactly what we did with Rapid Provisioning. You can now create a template which includes the OS answer file and which references a "dummy" blank VHD which is not going to used. Then, using Windows PowerShell (There is no GUI support for Rapid Provisioning since we expect customers to use this feature in massive deployments that are automated) you can execute the New-VM cmdlet and specify the local path to the VHD using a new switch –UseLocalVirtualHardDisk.

Here is a sample script where a new virtual machine is created by utilizing the local VHD d:\file.vhd without copying any VHDs over the network.

<<

#specify the file location
$VHDName = "d:\file.vhd"

#specify other variables for new-vm
$vmname = "vm1"
$hostname = "host.contoso.com"
$vmhost = get-vmhost $hostname

#create jobgroup ID for new-vm from template
$VMGuid = [System.Guid]::NewGuid().ToString()

#specify the local location for the VHD

#VMM expects that $VHDName already exists on the host computer when the new-vm cmdlet is called.
Move-VirtualHardDisk -Bus 0 -LUN 0 -IDE -Path $VHDName -JobGroup $VMGuid

#get the template name
$template = Get-Template | where {$_.Name -eq "template_2"}

#Get the current username to be passed as the VM owner
$callerUsername = whoami

#create the new-vm from template and specify the Rapid Provisioning flag (-uselocalvirtualharddisks)
New-VM -Template $template -Name $vmname -Description "" -Owner $callerUsername  -VMHost $vmhost -UseLocalVirtualHardDisks -Path $vmhost.VMPaths[0] -RunAsynchronously -JobGroup $VMGuid | Out-Null
 >>

 

Notice that using a similar methodology we could create a differencing disk from a VHD file on the host computer. Then, we could use this differencing disk as the target disk for the new virtual machine creation. This allows you to copy a single base disk with your OS on a host, and then use the Rapid Provisioning feature to create multiple Virtual Machines using differencing disks off that same base VHD. I have attached a PSM1 Windows PowerShell module that helps you do all of this and encapsulates them inside a new cmdlet. This module can be imported in your PowerShell console and exposes a new cmdlet called New-DiffVM. You can use this cmdlet to take advantage of rapid provisioning and do differencing disk standup of VMs. To use this module, see the cmdlets to execute below. The last cmdlet will create a new differeencing disk called child.vhd from the base disk base.vhd and create a new VM and attach it to child.vhd. This script and the entire Rapid Provisioning feature expects child.vhd to already exist on the host computer when new-vm is called. In addition, we expect the user that is executing this new cmdlet to be an administrator on the host computer so that it can create the differencing disk for the VM.

<<

PS > import-module .\NewDiffDiskVMModule.psm1

PS > get-help New-DiffVM  -detailed

New-DiffVM [-ParentVHDPath] <String> [-NewChildVHDPath] <String> [-HostComputerName] <String> [-VirtualMachineName] <String> [-TemplateName] <String> [-VirtualMachineServerName] <String> [-Verbose] [-Debug] [-ErrorAction <ActionPreference>] [-WarningAction <ActionPreference>] [-ErrorVariable <String>] [-WarningVariable <String>] [-OutVariable <String>] [-OutBuffer <Int32>]

 

PS > New-DiffVM -ParentVHDPath "d:\base.vhd" -NewChildVHDPath "d:\child.vhd" -HostComputerName "host.contoso.com" -VirtualMachineName "diffvm1" -TemplateName "template_2" -VirtualMachineServerName "vmmserver.contoso.com"

>>

 

In addition to the new UseLocalVirtualHardDisks, VMM 2008 R2 has added one more new flag called SkipInstallVirtualizationGuestServices. This flag allows you to skip the installation of the Integration Components (ICs) as part of New-VM if you are already certain that your template either contains the ICs or it contains an operating system that has built-in integration components. The New-VM cmdlet from the above example can be modified as below for this scenario. This will create a new VM using the local VHD filepath specified and will skill the IC installation. Furthermore, if your template has specified no OS customizations (meaning no sysprep or unattend actions will be executed), then New-VM can be completed in seconds!!!!

<<

#create the new-vm from template and specify the Rapid Provisioning flags (-uselocalvirtualharddisks and -SkipInstallVirtualizationGuestServices)
New-VM -Template $template -Name $vmname -Description "" -Owner $callerUsername  -VMHost $vmhost -UseLocalVirtualHardDisks -SkipInstallVirtualizationGuestServices -Path $vmhost.VMPaths[0] -RunAsynchronously -JobGroup $VMGuid | Out-Null

>>

 

These new features of VMM 2008 R2 will allow customers to rapidly create VIrtual Machines while leveraging their existing investments in SAN hardware. Keep the feedback coming folks :)

We have seen a lot of cases of customers trying to view the Virtual Machine Manager Self-Service Portal (SSP) UI from a computer running Windows Server 2008 R2 or Windows 7. If the portal is running VMM 2008, it is likely that you can't view the connections to a Virtual Machine and you are getting error "Virtual Machine Manager failed to connect to the virtual machine because the guest operating system's computer name XXX could not be resolved by the Domain Name System."

This error occurs because Windows 7 and R2 were not certified as client machines for the SSP of VMM 2008. VMM 2008 R2, which is in beta right now (beta is available from http://connect.microsoft.com) does support Windows 7 and Win2k8 R2 as a client of the SSP. The actual problem is because we are not identifying credssp correctly and we are trying to connect to the VM via regular RDP through its computer name (In this case the VM does not have a computer name that we can resolve with DNS).

 To correct this issue, you can either deploy VMM 2008 R2, or you can simply copy two files from an VMM 2008 R2 installaton into your VMM 2008 installation. You just need to update the ActiveX that we use to enable remote connections to the VM to work. Here is how:

1.      On your web server where the SSP is installed, open the location %programfiles%\Microsoft System Center Virtual Machine Manager 2008\wwwroot\activex

2.      Replace the vmmctlx_amd64.cab and vmmctlx_i386.cab files with the versions from our VMM 2008 R2 Beta (you need to install this beta on one computer to extract these files. Only the installation of the SSP will put these files on disk on the same location as listed above).

a.      You can install our VMM2008 R2 Beta from Microsoft Connect 

3.      Your Self Service users will then have to go to their “Programs and Features” and uninstall the “Virtual Machine Manager Self-Service Client”.  Then when they view the SSP website again, the newer version of the ActiveX will be installed and the VM console connection should work

The much anticipated VMM 2008 R2 beta is now released. You can go to http://connect.microsoft.com/ and sign up for the beta. Click on "Connection Directory" and sort by the newest beta programs or search for "System Center Virtual Machine Manager 2008 R2 Beta"

What's New in VMM 2008 R2 Beta

System Center Virtual Machine Manager 2008 (VMM) is a comprehensive management solution for managing virtualized infrastructure running on Windows Server 2008 with Hyper-V, Virtual Server 2005 R2 and VMware ESX through Virtual Center.  Recently, Windows Server 2008 R2 Beta was released which included significant feature improvements to Hyper-V-the underlying hypervisor platform.  A corresponding beta version of VMM R2 - the next version of VMM - is due for release shortly.  VMM R2 Beta  leverages the new platform enhancements and extends the feature set of VMM 2008. This overview highlights the most important new and significantly enhanced features in the VMM 2008 R2 Beta:

Support for new features of Windows Server 2008 R2 Beta

  • Live Migration: - Seen through the VMM console, this enables administrators to move virtual machines from one machine in a virtual host cluster to another with no downtime. This allows administrators greater flexibility in responding to planned or unplanned downtime, provides higher machine availability and more robust fault tolerance within virtualized infrastructure. The basic requirements for Live Migration are that all hosts must be part of a cluster and host processors must be from the same manufacturer. Additionally all hosts in the cluster must have access to shared storage. No changes are required to existing virtual machines, network, or storage devices in moving from Quick Migration to Live Migration other than upgrading to beta versions of Windows Server 2008 R2 and VMM 2008 R2.
  • Hot addition/removal of VHDs: Allows the addition and removal of new virtual hard disks (VHDs) on a running virtual machine. This enables storage growth in virtual machines without downtime. Additionally, ‘live" VHD management allows administrators to take advantage of additional backup scenarios and readily use mission critical and storage-intense applications (eg: SQL Server and Exchange).
  • New optimized networking technologies: VMM 2008 R2 Beta supports two new networking technologies - Virtual Machine Queue (VMQ) and TCP Chimney - providing increased network performance while demanding less CPU burden. NICS that support VMQ, create a unique virtual network queue for each virtual machine on a host that can pass network packets directly from the hypervisor to virtual machine. This speeds throughput as it bypasses much of the processing normally required by the virtualization stack. With TCP Chimney, TCP/IP traffic can be offloaded to a physical NIC on the host computer reducing CPU load and improving network performance.

 Enhanced storage and cluster support

  • Clustered Shared Volumes (CSV): Provides a single, consistent storage space that allows virtual hosts in a cluster to concurrently access virtual machine files on a single shared logical unit number (LUN). CSV eliminates the previous one LUN per virtual machine restriction and coordinates the use of storage with much greater efficiency and higher performance. CSV enables the Live Migration of virtual machines in and out of the shared LUN without impacting other virtual machines. Enabling CSV on failover clusters is straightforward and easy to monitor through the VMM administrator's console; many storage configuration complexities prior to CSV have been eliminated.
  • SAN migration into and out of clustered hosts: This allows virtual machines to migrate into and out of clustered hosts using a SAN transfer, which automatically configures the cluster nodes to recognize and support the new workload.
  • Expanded Support for iSCSI SANs: Previously, only one LUN could be bound to a single iSCSI target whereas now -- with VMM 2008 R2 Beta -- multiple LUNS can be mapped to a single iSCSI target. This provides broader industry support for iSCSI SANs allowing customers more flexibility in choosing storage providers and iSCSI SAN options.

Streamlined process for managing host upgrades:

  • Maintenance Mode: Allows administrators to apply updates or perform maintenance on a host server by safely evacuating all virtual machines to other hosts on a cluster using Live Migration or putting those workloads into a saved state to be safely reactivated when maintenance or upgrades are complete. Maintenance mode is enabled for all supported hypervisor platforms on Windows Server 2008 R2 Beta.

Other VMM 2008 R2 Beta enhancements

  • Support of disjoint domains: Reduces the complexity of reconciling host servers with differing domain names in Active Directory and DNS. In these situations, VMM 2008 R2 Beta automatically creates a custom service principal name (SPN) configured in both AD and DNS allowing for successful authentication.
  • Use of defined port groups with VMware Virtual Center: On installation, VMM 2008 R2 Beta will present available port groups for VMM's use with VMware Virtual Center thus allowing administrators to maintain control over which port groups are used.

 

The Virtualization Detect (DetectVp.EXE) tool is the logo test for checking if the system meets the requirements for Microsoft Virtualization Software. This test checks virtualization support for both Intel and AMD processors.

You can find this tool here: http://msdn.microsoft.com/en-us/library/dd424588.aspx

More Posts Next page »
 
Page view tracker