VMM ReproVMM 2012 SP1 and R2 - Data collection
SCOtrace - Orchestrator TracingAutomated data collection for SCO
Unsupported Cluster ConfigurationScript and post
VMM State Recovery ToolRepair Database state errors
SC 2012 VMM CAFirst line of defense in troubleshooting
Orchestrator Text Manipulation
VMM Networking Poster Illustrates networking for VMM 2012 SP1
VMM 2012 Technical Documentation, including Step-by Step Guides
VMM 2012 Official Cmdlet Reference
VMM 2012 TechNet Launchpad
VMM 2012 PowerShell Cheat Sheet
VMM 2008 PowerShell Cheat Sheet
2008 R2 Guides and Reference Downloads!
VMM 2008 Interactive Decision Flow
Jonathan's Virtual Blog
Virtual Machine Manager - Orchestrator - Solutions and Guidance
When migrating from SCVMM 2008 Beta to the final release bits (RTM), a utility is required in order to complete the process successfully. This tool is no longer posted on the Microsoft 'Connect' site, but is still available by request from Microsoft Support. The name of the utility is 'upgradev2beta.exe'.
Migrating from VMM 2008 Beta to VMM 2008
Here it is. We have a new KB that details updates and hotfixes required for SCVMM, Hyper-V and Clustering. Read the article here.
I've commented on the hotfixes inline below, providing a Support Engineer's perspective.
Install these. No question.
950050 (http://support.microsoft.com/default.aspx?scid=kb;EN-US;950050/ ) Description of the update for the release version of the Hyper-V technology for Windows Server 2008
Note If these hotfixes are missing from a Hyper-V server, the System Center Virtual Machine Manager 2008 Admin Console lists the server status as Needs Attention. Hotfix 956774 should be installed on the Hyper-V servers and on System Center Virtual Machine Manager 2008 Server.
I would change this from 'Recommended' to 'Required' based on experience.
Install ALL hotfixes on ALL Hyper-V servers, whether SCVMM is involved or not. This is more than a recommendation based on cases I have worked.
Collecting traces while reproducing an issue is one of the best methods we have of determining the source of an issue. Microsoft engineers might ask for this information when you open an incident, or you may want to perform tracing on your own for review. Cheng wrote the original article that walks you through the process step-by-step. With the growing number of Windows Core installations a colleague of mine (MikeB) found that new instructions were needed to perform this same process. Bookmark his post. It's one for the toolbox.
How to capture a Dbgview trace from Windows Core