Creating and Importing OS Profile Definitions
An OS Profile definition document is an XML file that defines non-default treatment of files, folders or registry keys on a virtual machine (VM), providing special backup or data persistence. Generally, in a Shared VM, information stored on the system disk remains unchanged form the way it is when the VM is published. OS profile definitions provide a means of changing that default behavior for specific elements of the system disk. The definition of the treatment of an object is captured in a "feature" element under the Root element.
Click here for more detail about disk use in a VM.
For example, a user’s video settings are defined in a registry key, which is normally stored on the C:\ (system) drive. By default, any changes to the system disk do not persist between sessions. However, this registry entry can be defined to be preserved between sessions, so the user does not need to reset his display control each session. Each feature definition is applied across all users on a guest OS (except for the NxTop Administrator).
Each feature is defined separately under a Root element. An OS Profile definition file may contain multiple objects. Once imported into NxTop Center, each definition is listed separately.
<?xml version="1.0" encoding="utf-8"?>
<root>
<feature> … </feature>
Each feature is defined separately, and appears listed in NxTop Center as a separate definition. The next section describes the elements of a feature definition.
- Create the file using the editor of your choice. If you need an editor with XML features, consider Notepad++ (free). You can include as many features as you need in a single file. Save the file when complete. Be sure to save the file with utf-8 encoding.
- Once the XML document with feature definitions is created, import the file into NxTop Center.
Feature Definition
A Feature element describes a set of file system and registry entries related to an object that must be preserved across reboots and which may be subject to other special treatment.
Each Feature element has several sub-elements – ID, Name, Description, Author and Target – which are described below.
For example:
<feature>
<id uuid=”2DD300BA-BD82-4083-B040-AAC055B903E7”version=”1”/>
<name> Client-side Cache</name>
<description>Preserve client-side cache definitions.</description>
<author>Joe Doakes</author>
<target os=”XP,Vista”>
<filesystem folder=”c:\windows\CSC” backup=”true”>
</target>
</feature>
<feature>
<id uuid=”C8F90842-1F7D-42dd-B867-F00BB4D0E034” version=”5”/>
<name>Avg Database</name>
<description>Preserve AVG virus database across reboots.</description>
<author>Marcel Proust</author>
<target os=”XP,Vista”>
<filesystem folder =”\Windows\system32\drivers\avg”/>
<registry key=”\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Avg8”/>
</target>
<target os=”Vista”>
<filesystem folder =”\Program Files\Avg\VistaSP1\Extra”/>
</target>
</feature>
Each Feature element must have a universal unique identifier and a version.
The format is:
<id uuid="universal unique identifier" version="number"/>
Use a UUID generator to create a valid UUID value.
You can download a GUID generator (GUIDGen.exe) from Microsoft or use a value created on guidgen.com.
Include a version number to track versions of this OS Profile definition. If you import an updated version of the definition, it must have a later version number than the one on NxTop Center.
Each Feature element must have a human-readable name. The format is:
<name> text </name>
The import validation will check that the name is unique among features on the NxTop Center.
Names can contain any alpha-numeric characters, and cannot include any of the following characters:
/ \ [ ] : ; | = , + * ? < >
Each Feature element may have a human-readable description. This field appears in the list of features when selecting OS Profile definitions for an OS Policy. Use this element to describe the effects of the OS Profile definition so the NxTop Administrator can decide whether to include the feature.
The format is:
<description>text</description>
Each Feature element may have an Author element to identify the source of the feature.
The format is:
<author>text</author>
Each Feature element has one or more Target elements. A Target element contains the Filesystem and Registry elements that define the OS Profile definition. The OS attribute describes the operating systems to which these apply.
The format is:
<target os=”OS-values”>
(Filesystem elements)
(Registry elements)
</target>
OS-values is a comma-separated list of one or more operating system names. Currently, the valid operating systems values are “XP” and “Vista”.
The filesystem and registry elements can be in any order. The definition can include multiple elements of each.
A Filesystem element specifies a system folder whose contents are to persist across reboots. Unlike the default, this element on the system disk is to be saved with User Data and recalled when the VM starts up again. A file system element can include attribute settings to define whether files should be merged with updated versions at each publish, or which version to use in the event of a conflict between server and client versions of a file. These new rules do not affect registry elements.
The format is:
|
filesystem [folder|file]="path" |
[backup="true|false"] |
All folders (and files in the folders) nested beneath the named folder are included - unless directed by another filesystem element. For example:
<filesystem folder="/Program Files/Jiminy" backup="true" />
<filesystem folder="/Program Files/Jiminy/Project7/junk" backup="false" />
These two elements would cause all files for the Jiminy application to persist and to be backed up, except the Project7 junk files, which would not be backed up (but would persist between sessions).
Attributes
A file system element must include a folder or file attribute, and the path to the folder (all files in the folder) or file including the file name. Currently the C: drive is implicit and need not be specified. No other drive letter is valid.
A file system element may include one or more of the following attributes:
- backup - determines whether to backup the folder (true or false)
If backup =... The folder is ... true backed up false not backed up - merge - determines whether to merge this folder on each publish (true) or just initially (false)
If merge =... The folder is ... true merged on each publish false copied only initially If no value is provided, the merge attribute defaults to true.
- conflict - in the event of a conflict between the version of a folder downloaded from the server and one resident on the client, determines which one to use.
If conflict =... The version of the folder used is ... server downloaded on the server client residing on the client computer If no value is provided, the version from the server is used, and the conflict is noted in the event log.
Currently the C: drive is implicit and need not be specified. No other drive letter is valid. Currently only folders can be specified, not specific files.
A Registry element specifies a registry key whose values and data are to be preserved across reboots.
The format is:
<registry key="key" [backup="true|false" ] />
Keys start with the string "HKEY_LOCAL_MACHINE\".
Currently, registry keys can be preserved in their entirety only, including all subkeys and their data values. A registry element cannot include only specific data elements of a key.
Examples
The following examples are provided:
Importing an OS Profile Definition
Once the OS Profile definition XML file has been created, it needs to be imported into NxTop Center.
Step One
Click on Policies > OS Profiles > Definitions in the Navigation tree.
Step Two
Click Import. The import wizard appears in a pop-up window:
Step Three
- Location – select from the dropdown list:
- Import from local system (where your browser is running) or
- Import from Server (the File Import folder under NxTop Center).
- Specify the file:
- From local system: Browse to the file location and highlight the file.
- From server: select from the dropdown list of files in the import folder.
Click Finish
Step Four
NxTop Center reads the OS Profile Definition file, validating it. Any invalid elements are described in an error message.
Correct any issues and import the file again.
When all the elements of the file are valid, an information pop-up lists the feature definitions to be imported. Click OK.
You're Finished!
The feature definitions appear in the list of OS Profile Definitions on the navigation panel, and are available within NxTop Center for inclusion in OS Policies. See Creating Policies or Modifying Policies or for more details.
Previous
Next