• How to remove a VM with the "missing" status from the VMM console

    Occasionally, after a cluster failover, duplicate virtual machines may appear in the System Center Virtual Machine Manager (VMM) Administrator Console: one with a status of Missing, the other with a different status. The missing virtual machines can be difficult to remove. The script in this topic is a SQL Server script that removes the missing virtual machines for you.

    Note  The script removes all virtual machines with the status of Missing from the VMM database. The script does not delete any virtual machines from any host computer, whether it is a Hyper-V, Virtual Server, or VMware-based host.

     The following steps help you prepare your system and run the script:

     

     1.      Close the VMM Administrator Console.

    2.     Stop the Windows service named VMMService on the VMM server.

    3.     Make a full backup of the VMM database.

    4.     Install Microsoft SQL Server Management Studio Express on the same computer on which the VMM database is stored. 

     

     Tip Microsoft SQL Server Management Studio Express is a free download from Microsoft that you can find on the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=190524).

     

    5.     Open SQL Server Management Studio Express, select the VMM database, and then run the following SQL Server script. This should delete all missing virtual machines with a status of Missing from the VMM database. If the script was successful, you will see the following output: Commands(s) completed successfully.

    6.     After the SQL Server script has completed, restart the VMMService and open the VMM Administrator Console to verify that the missing virtual machines are now deleted.



    BEGIN TRANSACTION T1

    DECLARE custom_cursor CURSOR FOR

    SELECT ObjectId from

    dbo.tbl_WLC_VObject WHERE [ObjectState] = 220

    DECLARE @ObjectId uniqueidentifier

    OPEN custom_cursor

    FETCH NEXT FROM custom_cursor INTO @ObjectId

    WHILE(@@fetch_status = 0)

     BEGIN

     DECLARE vdrive_cursor CURSOR FOR

     SELECT VDriveId, VHDId, ISOId from

     dbo.tbl_WLC_VDrive WHERE ParentId = @ObjectId

     DECLARE @VDriveId uniqueidentifier

     DECLARE @VHDId uniqueidentifier

     DECLARE @ISOId uniqueidentifier

     OPEN vdrive_cursor

     FETCH NEXT FROM vdrive_cursor INTO @VDriveId, @VHDId, @ISOId

     WHILE(@@fetch_status = 0)

     BEGIN

      DELETE FROM dbo.tbl_WLC_VDrive

             WHERE VDriveId = @VDriveId

      if(@VHDId is NOT NULL)

      BEGIN

           

       DELETE FROM dbo.tbl_WLC_VHD

       WHERE VHDId = @VHDId

       DELETE FROM dbo.tbl_WLC_PhysicalObject

       WHERE PhysicalObjectId = @VHDId

      END

      if(@ISOId is NOT NULL)

      BEGIN

     

       DELETE FROM dbo.tbl_WLC_ISO

              WHERE ISOId = @ISOId

       DELETE FROM dbo.tbl_WLC_PhysicalObject

       WHERE PhysicalObjectId = @ISOId

      END

     

         FETCH NEXT FROM vdrive_cursor INTO @VDriveId, @VHDId, @ISOId

       END

     CLOSE vdrive_cursor

     DEALLOCATE vdrive_cursor

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

     DECLARE floppy_cursor CURSOR FOR

     SELECT VFDId, vFloppyId from

     dbo.tbl_WLC_VFloppy WHERE HWProfileId = @ObjectId

     DECLARE @vFloppyId uniqueidentifier

     DECLARE @vfdId uniqueidentifier

     OPEN floppy_cursor

     FETCH NEXT FROM floppy_cursor INTO @vfdId, @vFloppyId

     WHILE(@@fetch_status = 0)

     BEGIN

          DELETE FROM dbo.tbl_WLC_VFloppy

      WHERE VFloppyId = @vFloppyId

     

      if(@vfdid is NOT NULL)

      BEGIN

       DELETE FROM dbo.tbl_WLC_VFD

       WHERE VFDId = @vfdId

       DELETE FROM dbo.tbl_WLC_PhysicalObject

       WHERE PhysicalObjectId = @vfdId

     

      END

     

         FETCH NEXT FROM floppy_cursor INTO @vfdId, @vFloppyId

       END

     CLOSE floppy_cursor

     DEALLOCATE floppy_cursor

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

     DECLARE checkpoint_cursor CURSOR FOR

     SELECT VMCheckpointId from

     dbo.tbl_WLC_VMCheckpoint WHERE VMId = @ObjectId

     DECLARE @vmCheckpointId uniqueidentifier

     OPEN checkpoint_cursor

     FETCH NEXT FROM checkpoint_cursor INTO @vmCheckpointId

     WHILE(@@fetch_status = 0)

     BEGIN

          DELETE FROM dbo.tbl_WLC_VMCheckpointRelation

      WHERE VMCheckpointId = @vmCheckpointId

     

     

         FETCH NEXT FROM checkpoint_cursor INTO @vmCheckpointId

       END

     CLOSE checkpoint_cursor

     DEALLOCATE checkpoint_cursor

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

    ---------Clean checkpoint

     DELETE FROM dbo.tbl_WLC_VMCheckpoint

     WHERE VMId = @ObjectID

            exec [dbo].[prc_VMMigration_Delete_VMInfoAndLUNMappings] @ObjectId

            DECLARE @RefreshId uniqueidentifier

            exec [dbo].[prc_RR_Refresher_Delete] @ObjectId, @RefreshId

            DELETE FROM dbo.tbl_WLC_VAdapter

     WHERE HWProfileId = @ObjectId

            DELETE FROM dbo.tbl_WLC_VNetworkAdapter

     WHERE HWProfileId = @ObjectId

                   

            DELETE FROM dbo.tbl_WLC_VCOMPort

     WHERE HWProfileId = @ObjectId

            DELETE FROM dbo.tbl_WLC_HWProfile

            WHERE HWProfileId = @ObjectId

            DELETE FROM dbo.tbl_WLC_VMInstance

            WHERE VMInstanceId = @ObjectId

     DELETE FROM dbo.tbl_WLC_VObject

     WHERE ObjectId = @ObjectId

        FETCH NEXT FROM custom_cursor INTO @ObjectId

      END

    CLOSE custom_cursor

    DEALLOCATE custom_cursor

    COMMIT TRANSACTION T1

     

  • How to capture a Dbgview trace from Windows Core

    Occasionally I find it necessary to capture a Dbgview trace from a Core installation of Windows Server 2008.  This commonly occurs as more and more people use a Core server as their VMM Host in either a P2V or V2V scenario.  When troubleshooting such an issue, CSS may need to capture Dbgview traces from all three servers involved (VMM server, host and source).  What follows are the instructions to capture a Dbgview trace from a Windows Server Core installation.  For general instructions on how to setup/configure a Dbgview trace, please refer to Cheng’s blog.

    Steps to capture Dbgview trace on a Core server

    a.  Copy the folder with all the Dbgview files to a local folder off the root of C drive like C:\Dbgview

    b.  From an administrator’s command prompt change to the C:\Dbgview directory

    c.  Type odson.reg (if this fails, add the registry entry manually)

    d.  Type odsflags.cmd 255 (or 0xffffff alternatively)

    e. Restart services:

                    net stop vmmservice

                    net stop vmmagent

                    iisreset

                    net start vmmservice

                    net start vmmagent

    f.  Type dbgview.exe

    g.  Dbgview should start capturing data

    However, on some Windows CORE installations the following error message then appears.

    clip_image001

    The obvious answer is to add the following privileges to the logged on user:

    1. Load and unload device drivers
    2. Debug programs

    But how do you add those rights?  Since we don’t have any UI in Core there are two ways that I know of that you can configure this.

    1. Create a new template with these rights and apply to the Core server.
      1. On a non-Core server, open a new mmc
      2. Load the Security Templates snap-in 
      3. Right click on Security Templates, and select New
      4. Name the new template Debug
      5. Expand Debug, then Local Policies followed by User Rights Assignments
      6. Modify the necessary rights
      7. Save the new template
      8. Copy the template to the Core server
      9. Use the Secedit /configure to apply template

    I’ve included an example of a properly configured secedit command.

    secedit /configure /db hisecws.sdb /cfg hisecws.inf /overwrite /log hisecws.log

    In this example, the db hisecws.sdb is used.  However you can use really any database because we’re only using it for a very brief amount of time and not making any changes to it.  We merely need the place holder.  The hisecws.inf would be the name of the template created above (Debug.inf).

    The following link talks more about using the SECEDIT command.

    http://technet.microsoft.com/en-us/library/cc737638.aspx

    2. Another option is to either modify the default domain policy or create a new group policy object that includes these rights and apply to the OU where the Core server resides.  Then either wait for policy to refresh or run gpupdate /force to immediately apply the new policy.  This may be the easier way to go but not sure if this is possible in your environment.

    This is part of the fun with running Server Core J

    3. Another alternative would be to take the Host out of the equation altogether and simply try the P2V conversion to the VMM server directly as a test. 

  • How to move the SCVMM database to another server

    You may find yourself in the position of needing to move the SCVMM database from one server to another for various reasons.  For instance, this situation can occur when moving from local to remote SQL or from a stand-alone SQL server to a SQL cluster.  The following instructions are provided as a guideline on how to accomplish this move from a SCVMM perspective.

     

    Important

    It is strongly encouraged that before undertaking this process that a complete backup of the SCVMM database is captured

     

    There are two methods to accomplish the task of backing up and moving the SQL database.  You can use either SQL Server Management Studio or the built in scvmmrecover.exe tool built into SCVMM.

     

    Method #1 -- Using SQL Server Management Studio

    How to move SCVMM database to another server (local to remote SQL)

    1.     Take a backup of the existing VMM DB

    2.     Uninstall VMM with the Retain Data option

    3.     On the remote SQL server, import VMM db

    4.     Install VMM pointing at the new SQL server and using the imported VMM db

    5.     If any managed host has the status of Access Denied, right click and select Reassociate

     

     

    Method #2 -- Using the scvmmrecover.exe tool

    The scvmmrecover.exe tool is discussed in great detail at the following TechNet article:  http://technet.microsoft.com/en-us/library/cc956045.aspx

     

    More Information

    How to: Attach a Database (SQL Server Management Studio)

    http://technet.microsoft.com/en-us/library/ms190209.aspx

     

    How to: Attach a Database File to SQL Server Express

    http://technet.microsoft.com/en-us/library/ms165673.aspx

     

    SCVMM R2 operations Guide

    http://go.microsoft.com/fwlink/?LinkId=162004

     

     
  • KB969269 - VMM Admin Console crashes with errors 19999 and 1 as logged in VM Manager

    Anyone ever had problems with the admin console crashing?  How about the crash happening each time the admin console refreshes?  Or perhaps troubleshooting has identified that the problem only occurs when a particular host is refreshed?  Ever wonder why this is happening?  While there are many potential causes of this problem, I want to take a few minutes and discuss one potential cause and provide you with some possible workarounds. 

     

    The error messages displayed in the console are usually the typical 1612 (lost connectivity) or 1700 (during a refresh) and are only a symptom and not the underlying issue.  You’ll need to open the VMManager log and look for the following errors which contain NullReferenceException:

     

    Error      1/18/2009 3:21:27 PM    Virtual Machine Manager             19999    None    

    Description:  Virtual Machine Manager (vmmservice:6452) has encountered an error and needed to exit the process. Windows generated an error report with the following parameters:

    Event:VMM20

    P1(appName):vmmservice

    P2(appVersion):2.0.3444.0

    P3(assemblyName):E.Adhc.Operations

    P4(assemblyVer):2.0.3444.0

    P5(methodName):M.V.E.A.VirHostDatabaseUpdater.PostVirtualNetworkUpdate

    P6(exceptionType):System.NullReferenceException

    P7(callstackHash):d1e7

     

    Error     1/18/2009 3:21:27 PM    Virtual Machine Manager             1              None

    Description:  Virtual Machine Manager (vmmservice:6452) has encountered an error and needed to exit the process. Windows generated an error report with the following parameters:

    Event:VMM20

    P1(appName):vmmservice

    P2(appVersion):2.0.3444.0

    P3(assemblyName):E.Adhc.Operations

    P4(assemblyVer):2.0.3444.0

    P5(methodName):M.V.E.A.VirHostDatabaseUpdater.PostVirtualNetworkUpdate

    P6(exceptionType):System.NullReferenceException

    P7(callstackHash):d1e7

     

    The cause is that Windows is reporting 2 NICs with the same name on the Host computer.  This issue is a known bug and will be corrected in the next version.

     

    The workaround options at this point can be:

    a)      Update drivers in the hope that that resets names

    b)      Avoid binding VNs to either of the duplicate NICs

    c)       Disable all but one of the duplicate NICs on the host

    d)      Disable host refresh and only do on-demand refresh (for all hosts but the affected one)

    e)      Don’t manage the host with VMM

     

    Note:     Other causes have been reported that if the Host has NIC teaming enabled or has any ghosted NICs…

     

    So, now we know what the problem is but how do we resolve it?  Here are the steps that I use when confronted with this issue.  First, determine which Host is experiencing the problem.  Either of the following methods will work.

     

    1.       Use the devcon utility which can be downloaded from KB311272.  After installing devcon, open a command prompt and navigate to the directory where it’s located.  Then run the following commands.

    devcon listclass net

    devcon findall =net

     

    The output should be identical.  If not, then any additional devices will have to be manually deleted from the Host.

     

    2.       Open a command prompt and type the following command:

    systeminfo         (if local)

    systeminfo /s <machine_name> (if remote)

     

                                    The output will display all NICs for a given machine.

     

    Now the final step is to actually remove the ghosted NIC from the Host.  This can often be tricky if the managed host computer is running the Core flavor of Windows Server 2008.  If so, we'll have to use the DEVCON utility to remove the ghosted NIC.  However if you're running the full version of Windows you might want to consider skipping straight to #3 below and simply resolving this from the UI instead of the command line.

     

    1.       From the output from the previous devcon commands, locate the ghosted NIC.  The line will look similar to the following:

     

    PCI\VEN_14E4&DEV_1677&SUBSYS_01A81028&REV_01\4&22443A69&0&00E5: Broadcom NetXtreme 57xx Gigabit Controller

     

    2.       Remove the ghosted NIC by typing the following command:

    devcon remove @“PCI\VEN_14E4&DEV_1677&SUBSYS_01A81028&REV_01\4&22443A69&0&00E5”

     

    Another alternative would be something like this:

    devcon remove @“*DEV_1677&SUBSYS_01A81028&REV_01\4&22443A69&0&00E5” 

     

    3.       An alternative solution to remove the ghosted device is as follows:

    a.       Click Start, click Run, type cmd.exe, and then press ENTER.

    b.      Type set devmgr_show_nonpresent_devices=1, and then press ENTER.

    c.       Type Start DEVMGMT.MSC, and then press ENTER.

    d.      Click View, and then click Show Hidden Devices.

    e.      Expand the Network Adapters tree.

    f.        Right-click the dimmed network adapter, and then click Uninstall.

     

    For additional information on this process please refer to KB269155.

     

  • Domain functional level requirements for VMM

    This is a question that I see from time to time either on forums or from customers.  What is the domain functional level required for VMM?

    The answer is that VMM requires the domain functional level to be at least 2003 or higher.  It is not supported to install VMM on a 2000 level domain. 

    http://technet.microsoft.com/en-us/library/cc764231.aspx