* From Microsoft TechNet: We have tested DPM 2010 running in a Hyper-V Virtual environment and it is fully supported considering the following limitations, requirements.
1) The DPM storage pool disks cannot be .vhd's - they must be either iSCSI attached disks or Pass thru disks.
The following 4 types of disk configuration are supported as DPM storage pool in a Virtual machine.
A) Pass-through disk with host direct attached storage (DAS)B) Pass-through FC LUN which is attached to host.C) Pass-through iSCSI LUN which is attached to host.D) iSCSI LUN which is attached to VM directly.
2) Item level restore for protected Virtual machines is not possible because that requires the Hyper-V role to be installed on the DPM server, but is not possible if Virtualized.3) Short or Long term backup to tape will be limited to using iSCSI attached tape libraries, and we recommend a separate NIC for that connection.
Other than those limitations / restrictions, DPM runs fine in a VM.
As to your point #2 above: it is certainly possible to enable the Hyper-V role in a virtual machine. You just can't start any machines due to the lack of hardware support.For ILR, do the affected VMs need to be started? Or just mounted?If it's the former I can see that this won't work. If it's the latter, it should.
Hardware requirement:CPU: min 1GHz, dual core, recommended 2.33 quard coreRAM: min 4GHz, recommended 8GHzStorage pool: min 1.5 times the size of protected data, recommended 3 times.
http://technet.microsoft.com/en-us/library/ff399021.aspxFor the DPM database, DPM 2010 requires a dedicated instance of the 64-bit or 32-bit version of SQL Server 2008, Enterprise or Standard Edition, with Service Pack 1 (SP1). During setup, you can select either to have DPM Setup install SQL Server 2008 SP1 on the DPM server, or you can specify that DPM use a remote instance of SQL Server.
If you decide to have DPM Setup install SQL Server 2008 SP1 on the DPM server, you are not required to provide a SQL Server 2008 license.
The installation guide is here http://technet.microsoft.com/en-us/library/ff399503.aspx
Source: http://kb.wisc.edu/page.php?id=5294These are some of the important characteristics of Volume Activation 2.0 as implemented at the UW-Madison.
In November 2006, Microsoft rolled out their new volume license activation scheme, Volume Activation 2.0 (VA2). Windows desktop (Vista) was the first software released using VA2, but other Microsoft volume-licensed software will eventually follow. As of late 2010, the current versions of Windows Server, Office, Visio, and Project are also using VA2.
VA2 shifts some of the burden of authenticating software installations and protecting activation keys from Microsoft to institutional users. Microsoft believes that preventing software piracy is an issue for all parties, not just for Microsoft, and VA2 is the next step in turning that belief into an enforceable implementation.
Activation is not licensing; it's a means of ensuring that installations are licensed. The 2006-2010 Microsoft Desktop Campus Agreement that gives users the right to install the most recent version of Office and the Windows OS on computers owned by the UW-Madison is based on the number of Full Time Equivalent employees at UW-Madison, not on the number of computers at UW-Madison. Neither we nor Microsoft negotiated the Campus Agreement with the understanding that there was a fixed relationship between the number of employees and the number of computers eligible for upgrade to the latest version of Office or Windows at the UW-Madison.
The bottom line is that departmental users do not need to concern themselves with the number of licenses or the number of allowed installations on UW-Madison-owned computers. They only need to ensure that the machine can be legally upgraded using departmental media, which means that it must be owned by the UW-Madison (for all software) and have a full Windows OS license associated with it (for the Windows upgrade).
Link to Volume Activation 2.0 FAQ (from Microsoft): http://www.microsoft.com/licensing/existing-customers/product-activation-faq.aspx
What follows are the important characteristics of VA2 as implemented at the UW-Madison.
As I've described in the previous two installments, the KMS is a pretty simple and straight-forward service. When you think about, this makes sense because the only thing that it does is activate clients.
So how do you track what the KMS is doing and identify any issues? The first way is a vbscript located in %systemroot%\system32 named slmgr.vbs. This little script is the main way to interact with the KMS and the activation client. Running this script with –dli as an option will list the activation information for the local system; if the local system is a KMS, then will also list KMS related data including the number of clients that it has activated in total. Remember that this number is important because Vista clients won’t activate unless the KMS has already activated at least 25 clients and Server 2008 clients won’t activate unless 5 other systems have already been activated. The following screenshot shows the output of slmgr –dli on a KMS:
Of note are the following:
VOLUME_KMS_C_channel – The type of license key that was used to activate the system. For a KMS, this also indicates what type of clients it can activate, see Windows Activation – The KMS for details.
License Status – Indicates whether the local system has been activate or not.
Current Count – The number of client systems already activated.
DNS publishing enabled – Indicates whether this KMS system is publishing its SRV record in DNS.
slmgr –dlv displays the same basic information with some extra thrown in. This in shown in the next screenshot:
The two above commands also work on clients and show the same information minus the KMS specific items.
Both the KMS server and client add event log entries to track activations and activation requests. For the KMS server, there is a dedicated log view called Key Management Service located under Application and Services LOGs in the Event Viewer:
The KMS will add an entry to this log every time it receives a request for activation. They will look like the following:
The first field in the info section (marked by the red arrow), is the success/failure code; 0x0 is success.
For clients, two events will be placed into the standard Application Event Log with EventIDs of 12288 and 12289 and provider name of Microsoft-Windows-Security-Licensing-SLC. 12288 indicates a client request and which KMS server the request is being sent to (blacked out):
12289 indicates a reply from the KMS, the success/failure code (marked by the red arrow below) is the first field in the info section and is the same code listed by the event entry on the server side:
There are a handful of common error codes, the full list is available in the Volume Activation 2.0 Operations Guide in Appendix 2.
That’s the bulk of it. Like I said at the start, its a simple service that does only one thing: activate clients.