Checkpoints in SCVMM are managed Hyper-V Snapshots. Hyper-V snapshots are block-level at the VHD layer and serve great for development environments that need reversion capabilities but are not recommended in production.
For a good how-to guide for creating and managing checkpoints, you can look at the Technet documentation here:
As I said earlier, this is great for scenarios of testing patches, testing upgrades, or working with App-V/Softgrid sequencers. It does not work if you are trying to attain file-level backup/restoration capabilities.
Checkpoints/Snapshots will not give you file-level restoration capabilities, however. This must come through a solution from the guest operating system. Windows Server 2008 and Server 2008 R2 have built-in VSS-based backup features.
You should use the built-in backup features of the operating system within the guest operating system to do individual file-based backups.
Backup and Recovery Overview for Windows Server 2008
Backup and Recovery Overview for Windows Server 2008 R2
NOTE: If you plan to use checkpoints for virtual machines with SCVMM, you will want to ensure that you have merged or deleted all checkpoints before moving the virtual machines or else you will experience delays when migrating virtual machines over the network (using BITS) or during QSM (Quick Storage Migration.)
Even worse, you could have errors from these timeouts that could also result in potential corruption of the checkpoints\snapshots.
We speak of version lineage in MED-V, we are speaking of the model for version change control. Some application environments, such as Microsoft’s App-V (formerly called Softgrid) will use GUID identifiers to represent a version and separate it from the GUID identifier for the package itself. It allows App-V servers to manage versioning through its data store.
While there is a methodology for lineage in MED-V v1, it is very simple. It simply bases its version from the filename ending. Original image version will end in “_1” and will carry the underscore format. When you pack locally, or upload a new image to a MED-V server, it will always append
1.) Don’t use image names ending in “_1” when using the console. This will simply wind up having the image file names with confusing suffixes. For example, if you pack an image in the console and call it “XPImage_1,” it will pack it as “XPIMAGE_1_1.CKM” instead. Let the console do it for you.
2.) When you select an image to upload to a server, and you have multiple versions, it will upload only the latest one based solely on filename.
3.) Don’t modify version stamps outside of the console.. While you can do it, users often forget to modify the .INDEX file that corresponds and if there is any mismatch in expected file name between the .CKM file and its corresponding index file, the MED-V console will just ignore the image altogether.
4.) Deleting an image version from the console WILL delete the CKM file and INDEX file for the image. Be very careful when deleting images.
It is also important to understand that MED-V will always download the latest version whether it is from a MED-V image distribution server or even in the event of pre-staged folders. Even though TrimTransfer does not work with pre-staged images, version lineage does.
Support for multiple drives and volumes within a virtual PC (workspace) used by MED-V will depend on the version of MED-V being used. MED-V v2 only supports the use of one fixed disk volume within a single virtual hard disk (VHD.)
It is technically possible to use more than one partition/volume within a single virtual hard disk but it is not recommended if it can be avoided.
MED-V v1 supported the use of multiple virtual hard disks (VHDs.) In addition, MED-V also supported multiple volumes (drives) as well as the use of the SUBST command to mount drive letters to local directories.
Due to performance limitations of Virtual PC 2007 and the additional resources required for Internet Explorer version 8 and later to function properly, it is not recommended to use any version greater than Internet Explorer 7 in the MED-V 1.0 Workspace.
Only Windows Internet Explorer 6 SP2 and Windows Internet Explorer 7 are officially supported for the MED-V 1.0 SP1 workspace installation. This is referenced on the following link:
For Version 2 of MED-V, Windows Internet Explorer 6, Windows Internet Explorer 7, Windows Internet Explorer 8, and Windows Internet Explorer 9 are supported for the MED-V 2.0 workspace installation.
MED-V 1.0: Error: “MED-V Workspace cannot start because the version of Virtual PC on your computer is not supported by MED-V”
When you attempt to start a MED-V v1 workspace, if you get the following error, you may not have properly deployed all of the appropriate pre-requisites:
MED-V Workspace cannot start because the version of Virtual PC on your computer is not supported by MED-V.
This can happen if you upgraded MED-V v 1.0 to either v1.0 SP1 or SP2 and the updated Virtual PC 2007 QFE patch was never applied to the client (KB974918.MSP.)
You will need to verify that the version of Virtual PC on the computer is at least at version 6.0.213 to ensure the KB974918 patch has been deployed. This patch must be deployed in order to meet the supported requirements for operation.