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
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.
The obvious answer is to add the following privileges to the logged on user:
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.
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.
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.
Collecting traces while reproducing an issue is one of the best methods we have of determining the source
This could come in handy when troubleshooting Windows Core VMs… Feed: System Center Virtual Machine Manager
Summary In order to diagnose a failure scenario in System Center Virtual Machine Manager, it is normally