----------------------------------------------- 
Domain Time II Version v5.x Administrator Notes 
----------------------------------------------- 

These notes were originally written as a guide for admins upgrading from
Domain Time version 4.x to version 5.x. Version 5.1 was introduced in 2009,
so many of the "changes" will be unfamiliar to those who have only ever
used version 5.2.

Domain Time is a continuously-maintained product, with ongoing enhancements
and improvements. Please rely on the online documentation for complete,
up-to-date information:

https://www.greyware.com/changelog

Domain Time II Verison v5.x introduces significant performance improvements, 
new features, and other enhancements to the Domain Time II product line. This 
document does not cover all of the changes, but it does address important 
items to be aware of when installing or upgrading to version v5.x. 


-- Notable changes from version v4.x 

   *	Version v5.x only runs on Windows XP and above. Win9x, NT, or Win2000 
	systems should continue using version v4.x.

   *	The three main types of v4.x Windows Client services (Full Client, 
	Thin Client, and Ultra Thin Client) have been combined into a single 
	5.x Domain Time II Client. Existing v4.x Full, Thin, or Ultra Thin 
	Clients will be converted to v5.x Domain Time Client during upgrade. 
	Existing settings are preserved during the upgrade, so the v5.x 
	Clients will continue to perform the same functions as the v4.x 
	Clients did. EXCEPTION: The Thin client and Ultra Thin Clients may 
	need to be configured via the Control Panel Applet if you weren't 
	using the default settings on those Clients.

	Note that v4.x Thin and Ultra Thin Clients did not have Control Panel 
	Applets, but the v5.x Client does. You may delete the domtimec.cpl 
	file from the \System32 folder after installation/upgrade if you do 
	not want the applet to appear.

   *	The v4.x DOMTIME.INI template configuration file is no longer used 
	to determine the installation defaults for Server and Client. 
	Instead, a standard Windows registry file (dtserver.reg for Server 
	or dtclient.reg for Client) holds all the default settings. 

	The new .reg file can be edited in any text editor. The Control 
	Panel's advanced Import/Export page will read or write the file, 
	making sure that only appropriate entries are loaded or saved. The 
	Import/Export page also checks to make sure the .reg file is the 
	correct version (v5.x) and type (server or client) for the machine. 

   *	v5.x introduces the ability to configure many Client and Server 
	options using Windows Group Policies. The distribution folder 
	contains an administrative template file (domtime.adm) that you can 
	use to populate objects in your Group Policy Object Editor. Load the 
	domtime.adm template into the object as a "Computer Configuration" 
	template. See the Microsoft documentation for details on using Group 
	Policy templates.

   *	The Domain Time Windows Time Agent is no longer installed by default 
	during installation of Domain Time Client or Server. The "Windows 
	Time" button on the Advanced property page will only operate if the 
	Windows Time Agent is already present (either from an upgrade from 
	version v4.x or if manually installed from the distribution files).

	Version v5.x allows you to disable the Windows Time service entirely 
	in nearly all circumstances, so the additional configuration options 
	the Agent provides for W32Time are not required.

   * Masters and Slaves

	The master server for any given domain may use the following options 
	for obtaining the time:

	(a) use its own clock (not recommended unless you have a third-party 
	    hardware device of some kind maintaining the clock) 
	(b) use a list of time sources 
	(c) use the PDC of another domain (by specifying the domain name on 
	    the time source setup dialog; the PDC is looked up dynamically) 

	Note that option (c) is not a v4.x-style foreign slave relationship; 
	it merely allows the local PDC to easily obtain the time from another 
	PDC in the forest. The v4.x "foreign slave" relationship where local 
	PDCs would receive slave synchronization signals and replication 
	settings from the foreign PDC does not exist in v5.x. 

	Option (c) can also be used by any other server or client, not just
	the domain master server. Again, using this option does not make the
	machine a slave; it merely lets you specify the domain without having
	to specify the PDC. When the PDC-emulator role shifts, machines will
	automatically start using the new PDC-emulator without additional
	configuration.

	v4.x masters and slaves interoperate with v5.x masters and slaves, 
	but will not replicate security parameters or other v5.x information. 

   * Clients using DHCP Discovery

	Option 004 ("Time Servers") is used only for discovering DT2 servers. 
	If a server is listed in option 004 that doesn't support DT2 UDP, it 
	will be ignored. 

	DHCP Option 042 ("NTP Servers") is used to discover both NTP servers 
	and DT2 servers. If a server is listed in option 042, it will be 
	checked for NTP first. If NTP fails, it will be checked for DT2 UDP. 
	If it does not provide time under either of these two protocols, it 
	will be ignored. 

   * Clients set to match their server's time zone.

	v5.x clients will only request timezone information if the server is 
	configured to provide _both_ recommended timings and timezone info. 
	Clients may use either recommended times or timezone (or both 
	or neither), but it won't ask for the server's timezone unless the 
	server is also set to provide recommended timings. This is to cut down 
	on the relatively-expensive timezone calculations needed by both the 
	server and client when sharing timezones. It also reduces unnecessary 
	network traffic. 

-- Obtaining and Serving the time

   *	Domain Time components, except for test programs, only use DT2, NTP,
        and PTP protocols for getting the time. "DT2" includes the entire
	DT2 family: DT2 over UDP, DT2 over TCP, and DT2 over HTTP. 

	Other time protocols (TIME/ITP, Daytime, etc.) are of insufficient 
	resolution for good timekeeping, and are therefore not used for 
	obtaining the time on v5.x. Server continues to provide them, 
	primarily to service legacy devices. 

   *	HTTP proxy servers are no longer supported for getting the time via 
	Domain Time over HTTP. You must have a direct connection in order to 
	use this protocol. You may specify a non-standard port number by 
	appending a colon and port to the server's name (e.g. 
	timeserver.mynet.com:91) 

   *	You are no longer limited to four time sources and you may make 
	multiple requests (samples) of each time source. 

   *	Time sample analysis is much more sophisticated than in version v4.x. 
	Sample averaging and analysis is automatic based on how many servers 
	(and how many samples per server) you select. Averaging is enabled by 
	default, but you may turn it off. You may have multiple samples per 
	server with or without using averaging (the multiple samples will go 
	through the same statistical analysis as if they were individual 
	samples from multiple servers). 

   * Symmetric Key Authentication

	Version v5.x supports symmetric authentication (MD5 or SHA hashes of
	shared secrets). This type of authentication works between Domain Time
	v5.x servers and clients, or between Domain Time and any 
	properly-configured NTP v3.x or higher daemon (such as ntpd on 
	UNIX/Linux machines, hardware GPS clocks, etc.). 

	Domain Time server supports serving time with symmetric 
	authentication for client-server requests on NTP, DT2-UDP, DT2-TCP, 
	and DT2-HTTP. Domain Time server also supports broadcasting (both 
	NTP and DT2-UDP) with a shared key and MD5 or SHA hash. Clients
	configured with the same key validate the sending server by comparing
	the computed hash. 

	Slaves automatically replicate shared secrets from their Master. 
	Masters, Independent Servers and Clients must be provided with a 
	shared secrets list, either by manually entering them into the 
	Control Panel applet, by being upgraded importing a Domain Time v5.x 
	configuration .reg file, importing/exporting a standard ntp.keys 
	file. Clients running on domain member machines may also receive 
	their shared secrets from a Windows Group policy. 

-- Interaction with Windows Time (W32Time)

	Windows Time clients using NT5DS mode (the default) search the Active
	Directory hierarchy to find a server. They send a request for the 
	time using their machine RID as the authentication key, and expect 
	the returned timestamp to be authenticated by the server. Only a DC in 
	the client machine's domain can provide this type of authentication. 

	Domain Time v4.x Servers provided for Windows Time clients by setting
	the W32Time service's client portion to "NoSync" mode and allowing the
	W32Time service's server portion to serve NTP directly. Although the
	quality of the timestamps provided by W32Time is significantly 
	degraded, this approach allowed the DC running Domain Time to continue 
	serving	Windows Time clients. This workaround is no longer necessary.

	Domain Time v5.x provides integrated Windows authentication natively
	for both NTP and DT2 protocols. This means that W32Time clients	in 
	NT5DS-mode can get their time directly from any Domain Time II Server 
	running on a DC, exactly as if getting the time from the Windows Time 
	Service on that DC.

	Additionally, Domain Time v5.x clients can use the same Windows
	authentication model to obtain NTP time from DCs running either the
	Windows Time service or Domain Time.

	Windows authentication only works on domain member machines. The 
	machine on which the client is running must be joined to the domain 
	(or the forest) from which it gets the time. Windows authentication 
	is automatic; no configuration is necessary. NOTE: While the domain
	member getting the time may be any kind of machine, the domain
	member providing the time must be a DC. Only a DC can validate the
	request. Other servers will not know the shared secrets.

	W32Time in NT5DS-mode has distinct disadvantages:

	 (a) The W32Time NTP Server is inaccurate, so even if the DC's clock 
	   itself is well-synchronized, the time being served may not be.

	 (b) Other ntp clients (such as xntp) cannot synchronize with it.

	Domain Time's NTP Server has none of these disadvantages. It can 
	provide standard NTP (with or without NTP auth) at the same time 
	it provides NT5DS-mode timestamps, and all at extreme accuracy.

	It is therefore highly recommended you install Domain Time II v5.x 
	Server on all DCs. You _can_ install Domain Time v5.x Clients on a
	DC, but you will then need to enable W32Time in "NoSync" mode to 
	provide NT5DS-mode.

	Recommended settings:

	For v5.x Server on a DC: 

	 (a) Verify that the "NTP Server Enabled" checkbox is checked on 
	     the Domain Time II Server "Serve the Time" property page AND 

	 (b) the "Windows Time mode" dropdown on the "Advanced" property 
	     page is set to "Disabled"

	For v5.x Client on a DC: 

	 (a) The "Windows Time mode" dropdown on the "Advanced" property 
	     page should be set to "NoSync"

	**Reliable Time Provider 

	 DcDiag and other tools sometimes expect the Windows Time service 
	 to be running, even if it's not actually doing anything. 

	 Starting with v5.x, Domain Time Server, when installed on a DC, 
	 sets the system flags to indicate the machine is serving time and 
	 is a reliable time source. The DsGetDcName() function will report 
	 Domain Time Server v5.x machines on DCs as both time servers and 
	 reliable time sources. Domain Time Server on a non-DC will not 
	 change the existing system flags. 

	 You may override this behavior by editing the registry. In 
	 HKEY_LOCAL_MACHINE\Software\Greyware\Domain Time Server\Parameters, 
	 edit (or create) a REG_SZ (string) value called "Set Reliable Time 
	 Provider" and set its value to either "True" or "False" (the 
	 English words, without the quotation marks). If this value is 
	 present and set to True, Domain Time Server will set the two flags 
	 even if it is not running on a DC. This configuration has no 
	 meaning for Active Directory, since only DCs are examined for the 
	 flags. Other tools, however, may benefit from knowing that a 
	 reliable time source is present. If this value is present and set 
	 to False, then Domain Time Server will not change the flags. 

	**Cluster Service

	 The Windows Cluster has a default startup dependency on W32Time. 
	 It does not require the time service for any other purpose. Thus, 
	 the simple recommendation for installing Domain Time on clusters 
	 is to set W32Time to NoSync mode, which allows the service to be 
	 running to satisfy the startup dependency, but allows Domain Time 
	 to set the clock. 

	 However, you may replace the cluster's startup dependency if you 
	 want. After installing Domain Time Client or Server, you can edit 
	 the "DependOnService" value in the 
	 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\clussvc key 
	 to replace "W32Time" with "Domain Time Client" (or "Domain Time 
	 Server"). The cluster service will then wait until Domain Time has 
	 started before starting. You can then set the "Windows Time" 
	 setting on the Domain Time applet to Disabled.

-- Network considerations

   *    Domain Time now uses both TCP and UDP port 9909 (DT2) for basic 
	operations. Firewalls will need to pass both types of DT2 traffic, 
	even if NTP (port 123 UDP) is actually being used to synchronize the 
	time.

   *    Version v5.x can use either IPv4 or IPv6 (or both) for obtaining and 
	serving the time. IPv6 requires operating system support, which is 
	present by default in Vista or above, but must be specifically 
	installed/enabled on XP. Domain Time will function in IPv4-only mode 
	if IPv6 is not present. If both are present, you may choose which to 
	use, or let the system figure it out (see the Network property page 
	on the Server or Client Control Panel applet). 

   *    Version v5.x does not use the MS Networking "browse list" for primary
	machine discovery. Functions that formerly only used the browse list 
	now use various methods of automatic discovery and configuration, 
	including broadcast, multicast, and Active Directory enumeration via 
	LDAP. The Browse list remains available as an additional secondary 
	discovery method on some components

   * Broadcasts and Multicasts 

	Previous versions of Domain Time depended on directed broadcasts to 
	discover or signal machines on remote subnets. Multicasting is now 
	preferred for signals that are sent to other subnets. Broadcasts are 
	still used on the local subnet, primarily for automatic client/server 
	discovery or signaling of advisories and cascades (see below). 
	Some Domain Time components (such as Monitor and Audit Server) may 
	still allow directed broadcasts for backwards-compatibility, but this 
	is discouraged.

	The "Broadcasts and Multicasts" property page on the Server or Client 
	Control Panel applet shows the addresses and hop-count/TTL used for 
	broadcasts and 	multicasts. These values pertain to the following 
	functions: 

	-- Server uses them to send cascades and advisories 
	-- Server uses them as the listen addresses for IPv4 and IPv6 
	   multicast requests 
	-- Server uses them to send broadcast/multicast time (DT2 heartbeats 
	   and NTP time) 
	-- Server and Client use them to control the TTL for PTP multicasts
	-- Tools that don't have their own settings (for example, dtcheck.exe) 
	   use them for discovery and testing. Clients use them to discover DT2 
	   and NTP sources Clients use them as the listen addresses for IPv4 
	   and IPv6 multicast requests 

	If you are trying to control overall broadcasting and multicasting, it 
	is better to enable or disable the particular functions that use the 
	addresses (such as on the Serve the Time property page) rather than 
	disabling them on the Broadcasts and Multicasts page. Enabling or 
	disabling on the Broadcasts and Multicasts page can have unintended 
	consequences -- you may be trying to keep clients from sending 
	multicasts for discovery, but end up preventing servers from 
	communicating with their peers. 

	** NTP time broadcasts/multicasts

	  In order for Domain Time to send or receive NTP time broadcasts or 
	  multicasts, the Domain Time service must control the NTP port (123 
	  UDP). If running Domain Time II Server, the Windows Time service 
	  must be disabled (this is the recommended configuration anyway). If 
	  running Client, the W32Time service must either be disabled 
	  (preferred) or set to NoSync mode. 

    * Cascades and Advisories 

	  Cascade signals are use to keep the hierarchy in sync when a server 
	  sets its clock. v5.x cascade signals may be unicast, broadcast, or 
	  multicast (any combination). Each server has its own settings for 
	  whether or not it sends cascades, and if so, what type. Server can 
	  send broadcast IPv4 only, multicast IPv6 only, multicast IPv4 only, 
	  or any combination. IPv4 broadcasts are sent to 255.255.255.255. 
	  This is not configurable. If you need cascades to cross routers, 
	  you must use IPv4 or IPv6 multicast instead. 

	  If you are not using the Domain Hierarchy in order to coordinate
	  your clocks (that is, PDC-emulator at the top, time distributed
	  to other DCs, then workstations getting time from their nearest
	  DC), we recommend turning off Cascades and Advisories. You can
	  either disable reception on the Advanced tab of each Client's
	  Control Panel applet, or disable sending them on the 
	  Serve the Time/Domain Role tab of each Server's Control Panel
	  applet. Without cascades and advisories, each machine will
	  check with its source(s) according to the schedule you set.

-- Clock Control

	Domain Time v5.x includes significant improvements and optimization 
	of all timekeeping functions to maximize the accuracy and precision 
	of clock synchronization and timestamps. The default timing settings 
	are usually sufficient to obtain superior synchronization on most 
	systems.

	However, in order to provide for tuning to achieve maximum accuracy 
	(and to deal with the occasional poor-performing clock), v5.x exposes 
	or adds a large number of advanced clock control options. See the 
	online documentation for details. 

   * Leap Seconds

	The Windows family of operating systems does not support leap seconds
	natively. Leap seconds are simply unexpected one-second corrections
	as far as the operating system is concerned.

	Version 4.x of Domain Time applied leap seconds at the first timecheck
	following the leap. Version 5.x applies them at 23:59:59 on the last
	day of the month in which the leap occurs. You may disable the new
	behavior by setting "Leap Seconds Enabled" to False in the parameters
	key for the Domain Time service. The new behavior is enabled by default.

	Domain Time acquires pending leap second information only from NTP or
	PTP time sources. All queried NTP sources must agree that a leap is
	pending i order for Domain Time to schedule the leap. If the sources
	disagree, then the leap will be handled at the next timecheck after it
	occurs, and a warning notice that the leap indicators are inconsistent
	will be  placed in the log.

	Pending leap information is queried with each timecheck (NTP/PTP sources
	only), and maintained only while the Domain Time service is running.
	Restarting the Domain Time service will clear any pending leap second
	corrections. If the leap is still pending when the Domain Time service
	is restarted, it will be rescheduled for the appropriate time. If the
	leap occurs while the Domain Time service is stopped, the leap will be
	applied at the first timecheck after startup.

   * Clock Corrections vs. Alignments 

	Domain Time can correct the clock either by "stepping" (immediately 
	changing the time) or "slewing" (changing the time slowly). Stepping 
	and slewing only operate on variances of 1 millisecond or more. 

	Variances of less than 1 millisecond are "aligned," which is a 
	process very similar to slewing. Aligning involves temporarily 
	speeding up or slowing down the computer to make it match the time 
	source more closely. Sub-millisecond alignments are NOT considered 
	corrections, and will not show as corrections in Audit Server, 
	Domain Time statistics, or the drift graph. Variances of less than 1 
	millisecond will be reported as zero milliseconds, except in the 
	log file. 

	If your machine is stepped, the log file will say "Local clock 
	stepped" (followed by details on which direction, by how much, and 
	the protocol used to obtain the time. 

	If your machine is slewed, the log file will say "Local clock slewed" 
	(followed by the same details as for stepping). 

	If your machine is aligned, the log file will say "Local clock 
	aligned" (followed by the same details as for stepping or slewing). 

	Alignments happen automatically as long as slewing is enabled. The 
	only important thing to remember about alignments is that they are 
	not reported as clock corrections. 

   * Never Step
	
	By default, Domain Time will step corrections too large to slew (or if 
	slewing in that direction is disabled), and will also step the very 
	first correction after rebooting. In v4.x, you could change this behavior 
	by enabling the "Never Step Clock" option. In v4.x, "Never Step" really 
	meant "Do not step except on first boot or when triggered by an 
	administrator," which was a bit confusing.

	In v5.x, if Never Step Clock is enabled, Domain Time really will never 
	step the clock. The slew limits and direction permissions are not 
	overridden by triggers, the Control Panel applet, or reboot detection. 
	As a result, if you have Never Step Clock enabled, you will probably 
	have to set the clock manually after every boot to get the time 
	within range to begin slewing.   

	To provide greater control of the stepping process, v5.x introduces the 
	"Allow Stepping" setting. Allow Stepping is a bitmask of reasons to 
	allow stepping. If your v4.x machine had Never Step specified in the 
	registry, the value will be translated to an Allow Stepping value of 
	zero when upgrading to v5.x. In all cases, stepping will only be applied 
	if slewing is disabled or cannot correct the variance. 

   * Hi-precision API/Software Development Kit

	v5.x Servers and Clients provide an Application Programming Interface 
	(API) to allow developers to have access to Domain Time's internal 
	hectonanosecond-resolution, monotonically-advancing, UTC-correct
	timestamps. The Software Development Kit (sold separately) includes 
	all necessary .dlls, documentation, and sample code.


-- Wait for first synch

	Some third-party time-sensitive applications or services are set to
	auto-start when the machine boots, but may need to have the clock
	synchronized before providing services. Recall that the CMOS clock chip
	may be wildly inaccurate, and therefore the first synchronization after
	boot is normally treated specially, allowing jumps in time either backward
	or forward.

	NOTE: Setting your service to have a dependency on Domain Time is not
	sufficient, because this will only make your service wait until Domain
	Time is running. Service startup dependencies don't have any way to check
	to see if Domain Time has finished synchronizing the clock after starting.

	v5.x Servers and Clients export a Win32 named event your processes can
	monitor to determine when the clock is synchronized. If the event is
	unsignalled, Doman Time could not synchronize the clock (or has not
	synchronized it yet). If the event is signalled, Domain Time has
	successfully synchronized the clock at least once since the service
	started.

	To monitor this event in your own application or service, use the Win32
	API OpenEvent to obtain a handle to "Global\domtime-sync-status-synchronized"
	(case-sensitive), and then use any of the Win32 wait functions. For example,

	 DWORD WaitForSync()
	 {
	  HANDLE hHandle = OpenEvent(STANDARD_RIGHTS_READ | SYNCHRONIZE,
				  FALSE,
				  "Global\\domtime-sync-status-synchronized");

	  if (hHandle == NULL) return GetLastError();
	  WaitForSingleObject(hHandle,INFINITE);
	  CloseHandle(hHandle);
	  return NO_ERROR;
	 }
	
	The code snippet above tries to open the named event. If unsuccessful, it
	will return the error code. Otherwise, it will wait for the event to become
	signalled. If the event is already signalled, the wait will complete
	immediately. As soon as the event becomes signalled, the snippet closes the
	handle and returns NO_ERROR to let you know that Domain Time has successfully
	synchronized the clock.

	In your own code, you probably want to include more error checking, and allow
	for a timeout in case Domain Time isn't running or never manages to synchronize
	the clock.

	Alternately, as of version 5.2.b.20150516, Domain Time has a registry setting
	(REG_MULTI_SZ) in its Parameters key called "Dependent Services". If your
	program is a service, you may change it to manual start, and list its name
	in the Dependent Services entry (one per line). Domain Time checks this list
	after the first successful timecheck, and, if it finds a service listed that
	is set to manual start, but yet started, starts it. You may list services
	either by their display name (i.e., "Disk Defragmenter") or by their internal
	service name (i.e., "defragsvc"). Domain Time cannot launch foreground or
	background applications this way: only services are supported.

-- Other Items

   * New command-line option on DTServer and DTClient

	v5.x adds a command-line option "-reset" or "-re". This option is 
	useful only when combined with the upgrade option "-upgrade" or "-u" 
	-- if specified, the upgrade will read the initialization .reg file 
	as with a fresh install (i.e., overwriting any 
	existing values). If not specified, upgrade will leave any existing 
	values intact, other than necessary housekeeping to convert values to 
	the current version's format. 

   * Service Status Monitor protocol 

	Version v4.x supported the service status monitor, but it was an 
	undocumented feature used by only a few OEM customers. Version v5.x 
	supports the same protocol unchanged, but exposes it on the Control 
	Panel applet for easier configuration. 

	The service status monitor is a simple TCP/IP listener to which your 
	own programs can connect to check the status of the Domain Time service. 
	By default, it supports both UDP and TCP on port 9911. 

	For UDP, use sendto to send an empty (zero length) packet to the 
	target port and then use recvfrom to get the reply. For TCP, use 
	connect and then recv (you do not need to send any data). The service 
	status monitor will reply to either connection with a single text line 
	(CRLF terminated) indicating the status and version. 

   * Audit Server autodiscovery of Linux domtimed clients

	Older Linux clients do not send their serial number with a time 
	request, so Domain Time Server does not record them when they get 
	time, and Audit Server does not know of them by examining the 
	ephemera data. Upgrade to the newest Linux client if you need 
	Audit Server to discover your Linux machines automatically. 

   * DTRCPL (DT Remote CPL program) 

	The x64 version will run only on x64 systems, and can control either 
	x64 or x86 remote systems. The x86 version will run only on x86 systems, 
	but can control either x64 or x86 remote systems. If the architectures 
	of the local system and the remote system match (both x86 or both x64), 
	then DTRCPL will try to load the CPL installed in the remote system32 
	folder (in case it happens to be an older or newer version of the CPL). 
	If the architectures do not match, or if the CPL was not found on the 
	remote system, DTRCPL will look in the local system32 folder and the 
	Manager folder (if Manager is installed) to find the appropriate CPL. 

   * DTSLEW 

	This program may produce less precise results on Vista/2008/Win7 than it 
	does on NT4/XP/2003. If the imprecision shows, it is only with very 
	small corrections (milliseconds or seconds) over large periods of time 
	(minutes or hours). This is a known limitation arising from Microsoft's 
	virtualization of the timing scheme on newer operating systems (fixed
        as of Win8/2012 and newer).

--MANAGER

	When performing a remote upgrade of a software component using Manager, 
	the selected template .reg file's contents do not replace the existing 
	registry contents on the target machine. Only settings present in the 
	.reg file that do not exist in the registry will be added. Existing 
	registry values will be unchanged.

	During remote installation, or during Reset Configuration of a software 
	component from Manager, the contents of the .reg file will be added to 
	the target machine's registry, overwriting any matching values already 
	present. Values present in the registry but absent from the reg file 
	will not be deleted (unless the reg file contains delete instructions 
	for values or keys).

	Manager's Reset Configuration procedure doesn't touch the dtserver.reg 
	or dtclient.reg installation defaults files on the target machine; it 
	creates a dtupdate.reg file instead, which the service then imports 
	and renames.
