Dario IT Solutions Blog

I’ve summarized several notes about Hyper-V and VMM. It may be useful for you to take it into account when planning or handling Hyper-V platforms.

1. Enabling NLB on a VM
Follow this procedure in case you need to enable NLB on a VM running under Hyper-V 2008. http://support.microsoft.com/kb/953828
Note that when your VM is running under Hyper-V 2008 R2, you will no longer need to specify a certain MAC. You will only need to check the option to “Enable MAC spoofing”.
Follow this link for detailed steps: http://robwhitehouse.com/virtualisation/enable-nlb-in-a-hyper-v-guest/

2. Max CPUs per VM
This Technet article shows the max number of allowed CPUs per VMs : http://technet.microsoft.com/en-us/library/cc794868(WS.10).aspx

3. Disk alignment
Set the disk alignment on two levels:

1. On the storage level. Set the alignment of the LUN so that the disk that the Host OS sees will see blocks the same as you storage device.
   Follow this link for best practices for Hyper-V on NetAPP : http://www.netapp.com/us/communities/tech-ontap/tot-hyperv-best-practices-0911.html
   Follow this direct link for the complete document, where you will find additional information regarding disk alignment : http://media.netapp.com/documents/tr-3702.pdf
2. Within the VHD. After aligning the partition on the LUN on the Host server, you should also align the partition that exists within the VHD file. The above link to the NetAPP documentation shows this procedure as well. You should notice, though, these point:

i. 2008 R2 allows you to mount a VHD to the host (without booting it to a VM). This allows you to create / change / align partitions from the host itself, before creating the VM.

ii. Aligning the VHD is only relevant for fixed virtual disks. Alignment of Incremental or dynamic disks won’t last, due to the nature of the file.

4. IDE / SCSI
Your boot disk has to be connected to an IDE controller on the VM (SCSI controller is a synthetic device http://technet.microsoft.com/en-us/magazine/2008.10.hyperv.aspx?pr=blog ). Connect all Other drives to a SCSI controller for better performance.controller.

5. Pass Through Disks
For best application disk performance, use Pass-Through disks. Pass-Through disks will give the VM direct access to a physical drive. For more information on this feature: http://technet.microsoft.com/en-us/library/cc768521(BTS.10).aspx

6. Moving VMs from 2008 to 2008 R2
After moving VMs from a Server 2008 to Server 2008 R2 be sure to install the integration services again.

7. General Host / VM Performance
Follow this link for explanation about measuring basic Memory / CPU / Disk performance: http://technet.microsoft.com/en-us/magazine/2008.08.pulse.aspx?pr=blog . Pay special attention to the disk monitoring. It is very likely that you’ve placed several disk intensive VMs on the same LUN.

8. Disconnect ISO files
When working on a Hyper-V cluster, make sure that you disconnect any ISO file from a VM when you’re done using it. Otherwise, when moving or live migrating your VM, it may fail because it wouldn’t find the ISO to connect to on the other node.

9. What’s new in VMM 2008 R2
http://www.microsoft.com/systemcenter/virtualmachinemanager/en/us/whats-new-r2.aspx

10. Disk size planning
When planning the size of the disk holding the VM’s VHDs, make sure that you have enough free space to save also the VM’s snapshots and entire memory. When Saving / Moving or Live Migrating the VM, the VM’s entire memory content is saved to disk.

Microsoft announced the release of the System Center Operations Manager 2007 R2 Connectors!  This is an important milestone as it provides a foundation for interoperability with other products, both external and internal.  The Connectors are available for download at the following location:

http://www.microsoft.com/downloads/details.aspx?FamilyID=592e4143-c5c8-4270-9a7a-cd0a31ab3189

The Operations Manager 2007 R2 Connectors provide Operations Manager 2007 R2 alert forwarding to remote systems, such as an Enterprise Management System (EMS) or a help desk system. After Operations Manager 2007 R2 forwards an alert to a remote system, the alert data is synchronized throughout the lifetime of the alert.  The result of that data synchronization is a robust and seamless systems management environment. Such an environment enables cross-organization support processes to take advantage of the resources and strengths of formerly independent support groups. The ultimate effect is improved enterprise systems health through improved organizational communication.

Sharing data between Operations Manager 2007 R2 and remote systems enables enterprise correlation of events from Windows-based systems, hardware, network, and UNIX systems. Correlating these events allows IT staff to determine the causes of issues and reduce the time to resolution of IT outages.

Synchronization of data between Operations Manager 2007 R2 and remote systems also enables operational groups to use familiar management interfaces. Users update an alert by using their management tool, and the data is updated in tools that are used by other operational groups.

The following connectors are available in this initial RTM:

1. Operations Manager 2007 R2 Connector for IBM Tivoli Enterprise Management Console
2. Operations Manager 2007 R2 Connector for HP Operations Manager (formerly HP OpenView Operations)
3. Operations Manager 2007 R2 Connector for BMC Remedy Action Request System (ARS)
4. Operations Manager 2007 R2 Universal Connector

For more information regarding the Connectors, you can review the following resources:

Download Details:

- http://www.microsoft.com/downloads/details.aspx?FamilyID=592e4143-c5c8-4270-9a7a-cd0a31ab3189

TechNet Documentation:

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

TechNet Forums:

- General:  http://social.technet.microsoft.com/Forums/en-US/interopgeneral/threads

- Connector for IBM Tivoli Enterprise Console:  http://social.technet.microsoft.com/Forums/en-US/interoptivoli/threads

- Connector for HP Operations Manager:  http://social.technet.microsoft.com/Forums/en-US/interophpoperationsmanager/threads

- Connector for BMC Remedy ARS:  http://social.technet.microsoft.com/Forums/en-US/interopremedy/threads/

- Universal Connector:  http://social.technet.microsoft.com/Forums/en-US/interopuniversalconnector/threads

SCCM uses a lot of log files, it could be quite confusing finding what you need. I gathered a list of all the log files and a description of their content to make life easy.

The client logs are located in the %WINDIR%\System32\CCM\Logs folder or %WINDIR%\SysWOW64\CCM\Logs (for x64 OS).
The SCCM server log files are located in the <INSTALL_PATH>\Logs or SMS_CCM\Logs folder.

IIS logs can be found in %WINDIR%\System32\logfiles\W3SVC1 folder.

NOTE: Use the Trace tool included in the SCCM Toolkit or MS Log Parser to easily view log files.

Client Log Files

• CAS – Content Access Service. Maintains the local package cache.
• Ccmexec.log – Records activities of the client and the SMS Agent Host service.
• CertificateMaintenance.log – Maintains certificates for Active Directory directory service and management points.
• ClientIDManagerStartup.log – Creates and maintains the client GUID.
• ClientLocation.log – Site assignment tasks.
• ContentTransferManager.log – Schedules the Background Intelligent Transfer Service (BITS) or the Server Message Block (SMB) to download or to access SMS packages.
• DataTransferService.log – Records all BITS communication for policy or package access.
• Execmgr.log – Records advertisements that run.
• FileBITS.log – Records all SMB package access tasks.
• Fsinvprovider.log (renamed to FileSystemFile.log in all SMS 2003 Service Packs) – Windows Management Instrumentation (WMI) provider for software inventory and file collection.
• InventoryAgent.log – Creates discovery data records (DDRs) and hardware and software inventory records.
• LocationServices.log – Finds management points and distribution points.
• Mifprovider.log – The WMI provider for .MIF files.
• Mtrmgr.log – Monitors all software metering processes.
• PolicyAgent.log – Requests policies by using the Data Transfer service.
• PolicyAgentProvider.log – Records policy changes.
• PolicyEvaluator.log – Records new policy settings.
• Remctrl.log – Logs when the remote control component (WUSER32) starts.
• Scheduler.log – Records schedule tasks for all client operations.
• Smscliui.log – Records usage of the Systems Management tool in Control Panel.
• StatusAgent.log – Logs status messages that are created by the client components.
• SWMTRReportGen.log – Generates a usage data report that is collected by the metering agent. (This data is logged in Mtrmgr.log.)

Server Log Files

• Ccm.log – Client Configuration Manager tasks.
• Cidm.log – Records changes to the client settings by the Client Install Data Manager (CIDM).
• Colleval.log – Logs when collections are created, changed, and deleted by the Collection Evaluator.
• Compsumm.log – Records Component Status Summarizer tasks.
• Cscnfsvc.log – Records Courier Sender confirmation service tasks.
• Dataldr.log – Processes Management Information Format (MIF) files and hardware inventory in the Configuration Manager 2007 database.
• Ddm.log – Saves DDR information to the Configuration Manager 2007 database by the Discovery Data Manager.
• Despool.log – Records incoming site-to-site communication transfers.
• Distmgr.log – Records package creation, compression, delta replication, and information updates.
• Hman.log – Records site configuration changes, and publishes site information in Active Directory Domain Services.
• Inboxast.log – Records files that are moved from the management point to the corresponding SMS\INBOXES folder.
• Inboxmgr.log – Records file maintenance.
• Invproc.log – Records the processing of delta MIF files for the Dataloader component from client inventory files.
• Mpcontrol.log – Records the registration of the management point with WINS. Records the availability of the management point every 10 minutes.
• Mpfdm.log – Management point component that moves client files to the corresponding SMS\INBOXES folder.
• MPMSI.log – Management point .msi installation log.
• MPSetup.log – Records the management point installation wrapper process.
• Ntsvrdis.log – Configuration Manager 2007 server discovery.
• Offermgr.log – Records advertisement updates.
• Offersum.log – Records summarization of advertisement status messages.
• Policypv.log – Records updates to the client policies to reflect changes to client settings or advertisements.
• Replmgr.log – Records the replication of files between the site server components and the Scheduler component.
• Rsetup.log – Reporting point setup log.
• Sched.log – Records site-to-site job and package replication.
• Sender.log – Records files that are sent to other child and parent sites.
• Sinvproc.log – Records client software inventory data processing to the site database in Microsoft SQL Server.
• Sitecomp.log – Records maintenance of the installed site components.
• Sitectrl.log – Records site setting changes to the Sitectrl.ct0 file.
• Sitestat.log – Records the monitoring process of all site systems.
• Smsdbmon.log – Records database changes.
• Smsexec.log – Records processing of all site server component threads.
• Smsprov.log – Records WMI provider access to the site database.
• SMSReportingInstall.log – Records the Reporting Point installation. This component starts the installation tasks and processes configuration changes.
• SMSSHVSetup.log – Records the success or failure (with failure reason) of installing the System Health Validator point.
• Srvacct.log – Records the maintenance of accounts when the site uses standard security.
• Statmgr.log – Writes all status messages to the database.
• Swmproc.log – Processes metering files and maintains settings.

Admin Console Log Files

• RepairWizard.log – Records errors, warnings, and information about the process of running the Repair Wizard.
• ResourceExplorer.log – Records errors, warnings, and information about running the Resource Explorer.
• SMSAdminUI.log – Records the local Configuration Manager 2007 console tasks when you connect to Configuration Manager 2007 sites.

Management Point Log Files

• MP_Ddr.log – Records the conversion of XML.ddr records from clients, and copies them to the site server.
• MP_GetAuth.log – Records the status of the site management points.
• MP_GetPolicy.log – Records policy information.
• MP_Hinv.log – Converts XML hardware inventory records from clients and copies the files to the site server.
• MP_Location.log – Records location manager tasks.
• MP_Policy.log – Records policy communication.
• MP_Relay.log – Copies files that are collected from the client.
• MP_Retry.log – Records the hardware inventory retry processes.
• MP_Sinv.log – Converts XML hardware inventory records from clients and copies them to the site server.
• MP_Status.log – Converts XML.svf status message files from clients and copies them to the site server.

Mobile Device Management Log Files

• DmClientHealth.log – Records the GUIDs of all the mobile device clients that are communicating with the Device Management Point.
• DmClientRegistration.log – Records registration requests from and responses to the mobile device client in Native mode.
• DmpDatastore.log – Records all the site database connections and queries made by the Device Management Point.
• DmpDiscovery.log – Records all the discovery data from the mobile device clients on the Device Management Point.
• DmpFileCollection.log – Records mobile device file collection data from mobile device clients on the Device Management Point.
• DmpHardware.log – Records hardware inventory data from mobile device clients on the Device Management Point.
• DmpIsapi.log – Records mobile device communication data from device clients on the Device Management Point.
• dmpMSI.log – Records the MSI data for Device Management Point setup.
• DMPSetup.log – Records the mobile device management setup process.
• DmpSoftware.log – Records mobile device software distribution data from mobile device clients on the Device Management Point.
• DmpStatus.log – Records mobile device status messages data from mobile device clients on the Device Management Point.
• FspIsapi.log – Records Fallback Status Point communication data from mobile device clients and client computers on the Fallback Status Point.

Mobile Device Client Log Files

• DmCertEnroll.log – Records certificate enrollment data on mobile device clients.
• DMCertResp.htm (in \temp) – Records HTML response from the certificate server when the mobile device Enroller program requests a client authentication certificate on mobile device clients.
• DmClientSetup.log – Records client setup data on mobile device clients.
• DmClientXfer.log – Records client transfer data for Windows Mobile Device Center and ActiveSync deployments.
• DmCommonInstaller.log – Records client transfer file installation for setting up mobile device client transfer files on client computers.
• DmInstaller.log – Records whether DMInstaller correctly calls DmClientSetup and whether DmClientSetup exits with success or failure on mobile device clients.
• DmInvExtension.log – Records Inventory Extension file installation for setting up Inventory Extension files on client computers.
• DmSvc.log – Records mobile device management service data on mobile device clients.

Operating System Deployment Log Files

• CCMSetup.log – Provides information about client-based operating system actions.
• CreateTSMedia.log – Provides information about task sequence media when it is created. This log is generated on the computer running the Configuration Manager 2007 administrator console.
• DriverCatalog.log – Provides information about device drivers that have been imported into the driver catalog.
• MP_ClientIDManager.log – Provides information about the Configuration Manager 2007 management point when it responds to Configuration Manager 2007 client ID requests from boot media or PXE. This log is generated on the Configuration Manager 2007 management point.
• MP_DriverManager.log – Provides information about the Configuration Manager 2007 management point when it responds to a request from the Auto Apply Driver task sequence action. This log is generated on the Configuration Manager 2007 management point.
• MP_Location.log – Provides information about the Configuration Manager 2007 management point when it responds to request state store or release state store requests from the state migration point. This log is generated on the Configuration Manager 2007 management point.
• Pxecontrol.log – Provides information about the PXE Control Manager.
• PXEMsi.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created.
• PXESetup.log – Provides information about the PXE service point and is generated when the PXE service point site server has been created.
• Setupact.log Setupapi.log Setuperr.log Provide information about Windows Sysprep and setup logs.
• SmpIsapi.log – Provides information about the state migration point Configuration Manager 2007 client request responses.
• Smpmgr.log – Provides information about the results of state migration point health checks and configuration changes.
• SmpMSI.log – Provides information about the state migration point and is generated when the state migration point site server has been created.
• Smsprov.log – Provides information about the SMS provider.
• Smspxe.log – Provides information about the Configuration Manager 2007 PXE service point.
• SMSSMPSetup.log – Provides information about the state migration point and is generated when the state migration point site server has been created.
• Smsts.log – General location for all operating system deployment and task sequence log events.
• TaskSequenceProvider.log – Provides information about task sequences when they are imported, exported, or edited.
• USMT Log loadstate.log – Provides information about the User State Migration Tool (USMT) regarding the restore of user state data.
• USMT Log scanstate.log – Provides information about the USMT regarding the capture of user state data.

Network Access Protection Log Files

• Ccmcca.log – Logs the processing of compliance evaluation based on Configuration Manager NAP policy processing and contains the processing of remediation for each software update required for compliance.
• CIAgent.log – Tracks the process of remediation and compliance. However, the software updates log file, *Updateshandler.log – provides more informative details on installing the software updates required for compliance.
• locationservices.log – Used by other Configuration Manager features (for example, information about the client’s assigned site) but also contains information specific to Network Access Protection when the client is in remediation. It records the names of the required remediation servers (management point, software update point, and distribution points that host content required for compliance), which are also sent in the client statement of health.
• SDMAgent.log – Shared with the Configuration Manager feature desired configuration management and contains the tracking process of remediation and compliance. However, the software updates log file, Updateshandler.log, provides more informative details about installing the software updates required for compliance.
• SMSSha.log – The main log file for the Configuration Manager Network Access Protection client and contains a merged statement of health information from the two Configuration Manager components: location services (LS) and the configuration compliance agent (CCA). This log file also contains information about the interactions between the Configuration Manager System Health Agent and the operating system NAP agent, and also between the Configuration Manager System Health Agent and both the configuration compliance agent and the location services. It provides information about whether the NAP agent successfully initialized, the statement of health data, and the statement of health response.

System Health Validator Point Log Files

• Ccmperf.log -Contains information about the initialization of the System Health Validator point performance counters.
• SmsSHV.log – The main log file for the System Health Validator point; logs the basic operations of the System Health Validator service, such as the initialization progress.
• SmsSHVADCacheClient.log – Contains information about retrieving Configuration Manager health state references from Active Directory Domain Services.
• SmsSHVCacheStore.log – Contains information about the cache store used to hold the Configuration Manager NAP health state references retrieved from Active Directory Domain Services, such as reading from the store and purging entries from the local cache store file. The cache store is not configurable.
• SmsSHVRegistrySettings.log – Records any dynamic changes to the System Health Validator component configuration while the service is running.
• SmsSHVQuarValidator.log – Records client statement of health information and processing operations. To obtain full information, change the registry key LogLevel from 1 to 0 in the following location:HKLM\SOFTWARE\Microsoft\SMSSHV\Logging\@GLOBAL

Desired Configuration Management Log Files

• ciagent.log – Provides information about downloading, storing, and accessing assigned configuration baselines.
• dcmagent.log – Provides high-level information about the evaluation of assigned configuration baselines and desired configuration management processes.
• discovery.log – Provides detailed information about the Service Modeling Language (SML) processes.
• sdmagent.log – Provides information about downloading, storing, and accessing configuration item content.
• sdmdiscagent.log – Provides high-level information about the evaluation process for the objects and settings configured in the referenced configuration items.

Wake On LAN Log Files

• Wolmgr.log – Contains information about wake-up procedures such as when to wake up advertisements or deployments that are configured for Wake On LAN.
• WolCmgr.log – Contains information about which clients need to be sent wake-up packets, the number of wake-up packets sent, and the number of wake-up packets retried.

Software Updates Site Server Log Files

• ciamgr.log – Provides information about the addition, deletion, and modification of software update configuration items.
• distmgr.log – Provides information about the replication of software update deployment packages.
• objreplmgr.log – Provides information about the replication of software updates notification files from a parent to child sites.
• PatchDownloader.log – Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server.
• replmgr.log – Provides information about the process for replicating files between sites.
• smsdbmon.log – Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components.
• SUPSetup – Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file.
• WCM.log – Provides information about the software update point configuration and connecting to the Windows Server Update Services (WSUS) server for subscribed update categories, classifications, and languages.
• WSUSCtrl.log – Provides information about the configuration, database connectivity, and health of the WSUS server for the site.
• wsyncmgr.log -Provides information about the software updates synchronization process.

WSUS Server Log Files

• Change.log – Provides information about the WSUS server database information that has changed.
• SoftwareDistribution.log – Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.

Software Updates Client Computer Log Files

• CAS.log – Provides information about the process of downloading software updates to the local cache and cache management.
• CIAgent.log – Provides information about processing configuration items, including software updates.
• LocationServices.log – Provides information about the location of the WSUS server when a scan is initiated on the client.
• PatchDownloader.log – Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.
• PolicyAgent.log – Provides information about the process for downloading, compiling, and deleting policies on client computers.
• PolicyEvaluator – Provides information about the process for evaluating policies on client computers, including policies from software updates.
• RebootCoordinator.log – Provides information about the process for coordinating system restarts on client computers after software update installations.
• ScanAgent.log – Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
• ScanWrapper – Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.
• SdmAgent.log – Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates.
• ServiceWindowManager.log – Provides information about the process for evaluating configured maintenance windows.
• smscliUI.log – Provides information about the Configuration Manager Control Panel user interactions, such as initiating a Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on.
• SmsWusHandler – Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers.
• StateMessage.log – Provides information about when software updates state messages are created and sent to the management point.
• UpdatesDeployment.log – Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.
• UpdatesHandler.log – Provides information about software update compliance scanning and about the download and installation of software updates on the client.
• UpdatesStore.log – Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.
• WUAHandler.log – Provides information about when the Windows Update Agent on the client searches for software updates.
• WUSSyncXML.log – Provides information about the Inventory Tool for the Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.

Windows Update Agent Log File

• WindowsUpdate.log – Located in %WINDIR%. Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.

(Taken from: HELO Windows Blog- http://blogs.msdn.com/lxchen/archive/2009/04/03/a-list-of-sccm-log-files.aspx)

http://en.wikipedia.org/wiki/Moravec%27s_paradox

Take a look at this picture:

Is there any chance it looks like a datacenter to you?

Well, believe it or not, but it is. it�s actually the 4th generation of Microsoft datacenter design. A couple of very interesting posts has been published by the design team, I highly recommend you check them out:

Our Vision for Generation 4 Modular Data Centers – One way of Getting it just right . . .

Microsoft’s Generation 4 Data Center Vision – the Architects’ Perspective

Based on hypervisor technology, the Hyper-V™ virtualization feature in the Windows Server® 2008 operating system is a thin layer of software between the hardware and the operating system that allows multiple operating systems to run, unmodified, on a host computer at the same time. Hyper-V is a powerful virtualization technology that can be used by corporate IT to consolidate under-utilized servers, lowering total cost of ownership (TCO) and maintaining or improving quality of service (QoS). Hyper-V opens more potential development and test environment types that otherwise might be constrained by hardware availability.

It is challenging enough in general to right-size the hardware to consolidate current workloads and provide headroom for growth. Adding virtualization to the mix increases the potential capacity planning challenges. The goal of this document is to help address these by focusing on two key areas of running Microsoft® SQL Server® in a Hyper-V environment:

• System resource overhead imposed by running SQL Server in a Hyper-V environment

• How well Hyper-V scales running SQL Server 2008

This white paper describes a series of test configurations we ran, which represented a variety of possible scenarios involving SQL Server running in Hyper-V. The paper discusses our results and observations, and it also presents our recommendations. Our test results showed that SQL Server 2008 on Hyper-V provides stable performance and scalability. We believe Windows Server 2008 Hyper-V is a solid platform for SQL Server 2008 for the appropriate workload. It is practical to run production workloads under a Hyper-V environment, as long as the workload is within the capacity of your Hyper-V guest virtual machine.

For more information, please refer to the whitepaper Running SQL Server 2008 in a Hyper-V Environment – Best Practices and Performance Recommendations.

I had the opportunity today (16.9.08) to participate in Microsoft�s getVIRTUALnow event, and to present the session “Physical and Virtual Server Management”

I presented my take on data center management, which involves automating management tasks in response to system\application states.

It was impressive to see the number of vendors that were present in the event. Microsoft seem to be quick in building the required ecosystem of partners that will push it’s Virtualization offerings greatly in my opinion.

The main point in my presentation was that when looking at the data center (or IT environment) as a whole, tools like Systems Center Operations Manger and Systems Center Virtual Machine Manager (that has integration built into them from the grounds up) really stand out in the crowd in comparison to tools that are built for a specific environment (like managing only virtual machines).

One of the demonstrations involved Performance Resource Optimization (PRO) which is one of VMM�s top features, as it allows administrators to automate practically any type of response to a given condition, including responding to application, virtualization, system, storage, or network events.

For more demonstrations, take a look at Liran’s post – “Get Virtual Now with Hyper-V Technology“.

Also, You are more then invited to check out a bunch of pictures we took at the event – http://www.facebook.com/album.php?aid=55996&id=15415483905&ref=mf

Have you ever thought that 9 auditing options available in Windows (via Local security policy or GPO) are too general? Have you ever asked to make more granular auditing?

Now you can. You have about 50 new subcategories to audit:

System
  Security State Change
  Security System Extension
  System Integrity
  IPsec Driver
  Other System Events
Logon/Logoff
  Logon
  Logoff
  Account Lockout
  IPsec Main Mode
  IPsec Quick Mode
  IPsec Extended Mode
  Special Logon
  Other Logon/Logoff Events
  Network Policy Server
Object Access
  File System
  Registry
  Kernel Object
  SAM
  Certification Services
  Application Generated
  Handle Manipulation
  File Share
  Filtering Platform Packet Drop
  Filtering Platform Connection
  Other Object Access Events
Privilege Use
  Sensitive Privilege Use
  Non Sensitive Privilege Use
  Other Privilege Use Events
Detailed Tracking
  Process Creation
  Process Termination
  DPAPI Activity
  RPC Events
Policy Change
  Audit Policy Change
  Authentication Policy Change
  Authorization Policy Change
  MPSSVC Rule-Level Policy Change
  Filtering Platform Policy Change
  Other Policy Change Events
Account Management
  User Account Management
  Computer Account Management
  Security Group Management
  Distribution Group Management
  Application Group Management
  Other Account Management Events
DS Access
  Directory Service Access
  Directory Service Changes
  Directory Service Replication
  Detailed Directory Service Replication
Account Logon
  Credential Validation
  Kerberos Service Ticket Operations
  Other Account Logon Events
  Kerberos Authentication Service

Here you can find additional information about auditing:

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

All events that are written to even log for each subcategory:

http://support.microsoft.com/default.aspx/kb/947226/en-us

And the way to enable and deploy it:

http://support.microsoft.com/kb/921469/en-us

Recommendation for enabling/disabling auditing subcategories are documented in Windows Server 2008 Security Guide:

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

Hyper-V have an option to use CIFS/SMB file server share as your option for Failover Clustering storage.

This solution can enable you to use Quick Migration and but only be truly highly available if you file share is also highly available.

Important performance issue – Windows Server 2008 file server does increased performance for this type of workload. However, this is no way near FC\iSCSI configurations and should be used only after throughout utilization tests.

Before and After Diagrams

Lets describe the scenario using two diagrams. First, here is a diagram describing the scenario before a failure:

Now, here�s a diagram describing the scenario after a failure in SPTNODE1:

As you can see, we use a file server (called SPTSERVER1) for storing the Hyper-V files. The idea is to store the configuration files, the VHD itself and the VHD snapshots in the \\SPTSERVER1\VMSHARE\VM1 folder. As we do when using a SAN for shared storage, the surviving node will take over and start the VM in case of a failure. We can also use the very same scenario for Quick Migration, making the VM move orderly from one node to another by saving the state to the file share and instructing to other node to take over and restore the VM.

Pre-requisites

Before you move forward, you want to make sure you have at least two physical computers running Hyper-V. In our scenario, STPNODE1 and STPNODE2 are running Windows Server 2008 Enterprise (Full or Core installs work fine).

Add the Hyper-V role to STPNODE1 and STPNODE2.

Add the Failover Clustering feature to STPNODE1 and STPNODE2.

You will need to use a general purpose server to act as a file server or a NAS box compatible with CIFS/SMB. You probably want to run Windows Server 2008 for improved performance (new TCP/IP stack and SMBv2 protocol). In our scenario, STPSERVER1 is the file server running Windows Server 2008 Enterprise Edition  (Full or Core installs work fine).

Grant the required permissions for \\SPTSERVER1\VMSHARE\ to the computer accounts for STPNODE1 and STPNODE2, as described at http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx.

You might also want to have a management client which could be your desktop (running Windows Vista SP1) or another server (running a Full install of Windows Server 2008). In our scenario, SPTCLIENT1 is the management client.

Install the Windows Server Hyper-V RTM patch.

You will need to have a domain infrastructure (Windows Server Failover Clustering requires a domain). The domain controller is not shown in the diagrams.

Steps

You start the process by creating a cluster with the two Hyper-V nodes. To do this, you will use the Failover Cluster Management MMC from either node. In that tool, you will:

1. Validate the configuration
2. Create the cluster
3. Adjust the quorum configuration
4. Create the virtual machine in one of the nodes
5. Make the VM highly available

Running Validation

Here�s the initial screen of the Failover Cluster Management MMC, when first loaded.

Before you create the cluster, you must Validate your Configuration. Be sure to run *all* Validation tests, since solutions are only supported if you do so.

Since we are not using shared storage, the storage tests will generate a warning.  Completing validation with a warning is acceptable.

If you run into any errors during Validation, you must fix those before you proceed.

Creating the Cluster

After you run validation, click the option to �Create a Cluster�. First, you must specify the nodes. In this case we�re using SPTNODE1 and SPTNODE2.

Second, you specify the name of the cluster.

After confirming the data entered, the cluster is created, as shown below:

Note that we end up with a warning (yellow triangle). If you click the �View Report� button, you find what the issue is:

No appropriate disk could be found for the quorum disk.

This is expected. With only two nodes with no shared storage, you don�t have a valid quorum configuration and a single node failure will cause the cluster to fail.

You can see that in the cluster information below:

Typically, in a shared storage configuration, you would get that third vote from a shared witness disk (also know as a quorum disk).

We will overcome that in the next step.

Configuring the Cluster Quorum Settings

To get our third vote for the cluster without using shared storage, we will use the new option in Windows Server 2008 Failover Clustering to use a file server witness.

First, you need to add permission for the cluster computer account to the file share. The cluster computer account was created when we created the cluster.

As you did when granting permissions to SPTNODE1 and SPTNODE2, add full control permissions for the SPTDEMO\SPTCLUSTER$ account in the share and in the file system at SPTSERVER1.

Next, use the Failover Cluster Management tool to change the Quorum Configuration.

You will find this option by right-clicking the cluster name, then selecting �More Actions�, as shown below:

The wizard will guide you through the process. You will select the option for �Node and File Share Majority�, as shown below:

In the next screen, you will specify the actual shared folder path for the file share witness resource. We will use \\SPTSERVER1\VMSHARE\WITNESS. See below:

After you confirm the operation, you will see the update in the quorum configuration, now showing no warning signs.

I would recommend that you also check the status of the storage in the cluster.

You do this by clicking on the �Storage� node under the cluster name in the Failover Cluster Management tool. Here�s what you should see at this point:

As you can see, this is one of the cases where you have a healthy cluster with no shared storage. Exchange Server 2007 CCR clusters also do that.

Creating a regular Virtual Machine on a cluster node

At this point, if you check the Hyper-V Manager tool, you will see no virtual machines:

Now we will use the Hyper-V Manager to create a new VM in SPTNODE1 using only a file share for storage. If you�re doing this from SPTNODE1, you should have no issues. If you�re doing this from any other computer (like the management client SPTCLIENT1), be sure to check this post on how to configure Constrained Delegation to allow remote management of Hyper-V when using file shares: 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

Again, this is done through a wizard. This is a regular VM creation, except for the fact that we�re using UNC paths (file share paths) for the storage, instead of regular folders on a local disk. In my specific case, we�re storing this new VM at \\SPTSERVER1\VMSHARE\VM1.

Here you see the virtual machine configuration folder:

Then the location of the new VHD file for the VM:

And even the ISO file we�re mounting will also come from that file server:

Once all is confirmed, we have a new VM, which you should keep in an �off� state for now:

Making the Virtual Machine Highly Available

Now we go back to the Failover Cluster Management tool to make the newly created VM highly available.

Click on the �Services and Applications� node under the cluster name and select the option to �Configure a Service or Application�. Again, it�s a wizard:

After selecting �Virtual Machine� as the type of service, you will select from a list of existing VMs. In our case, there�s only VM1:

After confirming your settings, the VM is made highly available, with a warning:

Again, if you click on the �View Report� button, you find the issues

The path ‘\\SPTSERVER1\VMSHARE\VM1′ where the virtual machine configuration is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine configuration on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1′ where the virtual machine snapshots are stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine snapshots on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\VM1\VM1.vhd’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

The path ‘\\SPTSERVER1\VMSHARE\ISO\WindowsServer2008-amd64.iso’ where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

As it usually does, the Failover Cluster Management tool is being very careful, pointing out that the file server share you are using is a potential single point of failure.

In order to have true high availability, you need to make sure that file share is also highly available. To achieve that, you need to place that file share in Failover Cluster as well.

The wizard has no way to detect if the file share is also clustered, so you will always get these warnings.

Now, you can go back and check the properties of the new highly available VM and bring it online.

One interesting thing you will notice is that you will not have any storage associated with that service, as you can see below:

In the summary page, you also confirm that, since you do not have the typical clustered disk listed in the summary for the virtual machine:

Moving the VM to another node

The last step is to prove that you can fail or move the VM to another node.

To do this, I use the option to �Move this service or application to another node�, which you can find when you right-click the virtual machine. See below:

When you do this, you will see that the VM will be taken offline in the source node (the state is saved first), as you can see below:

Then the VM will be brought online on the destination node (by restoring the state). Check below:

This process takes only a moment, and will depend only on how much memory you VM has and how long it takes to save the state to the file server share (from SPTNODE1) and then to restore the state from that same file share (from SPTNODE2).

You can see the final state, after the move to SPTNODE2 is completed, below:

More information can be found at source.

List of supported applications on Hyper-V:

http://support.microsoft.com/?kbid=957006

All, based on this press-pass published today. I think it will generate questions from our customers. In particular the section related to support:

Expanded Technical Support

Microsoft has updated its technical support policy for 31 server applications so that customers can receive technical support when deploying those applications on Windows Server 2008 Hyper-V, Microsoft Hyper-V Server or any other third-party validated virtualization platform. Now customers can get the same level of product support in a virtualized environment that they are accustomed to with non-virtual environments. More information is available at http://support.microsoft.com.

To enable this support policy, Microsoft launched the Server Virtualization Validation Program in June 2008. The program is open to any software vendor to test and validate its virtualization software to run Windows Server 2008 and previous versions of Windows Server. To date, Cisco Systems Inc., Citrix Systems Inc., Novell Inc., Sun Microsystems Inc. and Virtual Iron Software Inc. are participating in the program.

�Technical support of virtualized images is an industry-wide challenge,� said Roger Levy, senior vice president and general manager of open platform solutions at Novell. �Novell and Microsoft continue to collaborate to optimize bidirectional virtualization between Windows Server and SUSE Linux Enterprise with Xen. Microsoft�s Server Virtualization Validation Program provides customers with additional peace of mind when they run Windows as a guest in a validated environment such as SUSE Linux Enterprise.�