KB2001.728
Problem: '[Control] Access Denied' using Domain Time II Manager, Update Server, or Audit Server
This article applies to Domain Time II Manager,
Domain Time II Update Server, and
Domain Time II Audit Server
Last updated: 2/24/2008
Problem
When you try to control a remote machine using Domain Time II Manager, you get "Control Access Denied" and all (or most) of the buttons are grayed out.
Or you receive "Access Denied" messages when using Domain Time II Update Server or Domain Time II Audit Server.
Symptoms
Domain Time II Manager
Domain Time II Manager uses standard Microsoft Networking access to provide remote control
of other machines on your network. If Manager cannot obtain sufficient access, it will
display "Control Access Denied" on the details page, and all (or most) of the control buttons will be
grayed out.
If Manager can determine that Domain Time II Client (any type) or Domain Time
II Server is installed on the remote machine, but doesn't have remote control permission (such as when
using 32-bit Manager to remotely control a 64-bit system or vice versa)
it will enable the Sync Now, Reset Stats, and Refresh buttons. These functions only require
port 9909 UDP access, not full remote control permission.
Domain Time II Update Server
The Update Server service works very similarly to Manager in performing remote installs and upgrades using
Microsoft Networking. If it is unable to obtain sufficient network access to a remote system, installs and upgrades will fail
and "Access Denied" errors will be written to the service log.
Domain Time II Audit Server
Some features of Audit Server such as collecting sync log files from remote systems, or automatically updating the Audit List with
machines that have synchronized with Domain Time II Servers require remote file and registry access in the same manner as
Manager and Update Server. If the Audit Server service cannot obtain sufficient network access, these features will fail and
"Access Denied" errors will be written to the service log.
Details
Domain Time II components like Manager, Update Server, and Audit Server use three tests to verify remote access permission:
- Ping
The remote machine must respond to an ICMP echo request. If you are accessing
by IP number, then failure usually means the remote host is offline or that
ICMP has been blocked by a router between you and the remote machine. If you
are accessing by DNS or NetBIOS name, then you may not have proper DNS and/or WINS (or other)
NetBIOS-name-to-IP-address resolution set up on your network.
- File System
The remote machine must allow you to connect to its ADMIN$ share and read/write
files. This share exists by default on all Windows NT4/2K/XP/2003/Vista/2008 machines, and on all Win95/98/ME
machines as long as File and Print sharing is installed and enabled. Windows NT4/2K/XP/2003/Vista/2008 machines need to have
the File and Print Sharing Service running (on NT, this service is named the Server service).
- Remote Registry
The remote machine must allow you to connect to and read/write from its registry using the Remote Registry service.
Failure usually means that that you do not have administrative permissons to the remote machine or that the Remote
Registry service is not running there. Remote Registry is installed (but not always set to run by
default) on Windows NT4/2K/XP/2003/Vista/2008 systems. Remote Registry must be manually installed on Win9x machines.
See Microsoft's Q141460
for information about obtaining and installing the Remote Registry Service on Win9x.
Solution
Follow each of these steps and verify that each item is working correctly:
- Use the right version for your processor architecture
Be sure the machine you're using for Manager and/or Update Server has the same processor architecture as your target machines. 32-bit x86 versions of
Manager can only fully remote control or install/upgrade/configure other 32-bit x86 systems. 64-bit systems can only
remote control/install/upgrade/configure to other 64-bit systems. Alpha systems may only control Alpha systems, etc.
If you have a mixture of architecture types, you will need to use a separate machine running
Domain Time II Manager and/or Update Server for each machine type. However, please note that Manager is able to perform some basic functions
such as trigger synchronization on or view the stats from Domain Time components on other architectures.
Domain Time II Audit Server is not affected by this restriction. It will interoperate with Domain Time II components on any architecture type.
- Rule out any firewall issues
Verify that your network access is not being blocked by any firewalls, including personal firewalls. In particular, traffic over UDP port 9909
and TCP ports 137-139, 445 must be enabled between the Manager, Update Server, and/or Audit Server machine and the remote systems.
See Firewall and Router Issues for more details.
- Enable Network Discovery
Windows operating systems running Vista or later have a network function called Network Discovery,
which controls whether or not machines on the network are visible to each other for making network connections.
Network Discovery is actually a specific combination of services and firewall settings which are enabled or
disabled by settings in the Network and Sharing Center. If present on any system running Domain Time II
components, Network Discovery must be enabled so that the Domain Time II Manager, Update Server service, and/or Audit Server service
can ping the remote systems, connect to their administrative shares, and connect to their registry as necessary.
You must have at least the Network Discovery and File Sharing options enabled in Network and Sharing Center.
See Microsoft's
What is network discovery? page for more info.
- Verify Ping works correctly
Make sure you can ping the remote machine from the Domain Time Manager, Update Server, and/or Audit Server machine. Ask your
network administrator for assistance if you cannot ping the remote machine -- your firewall(s) may be preventing
ICMP traffic. Test by typing
ping machinename
at the command prompt (substituting the machine's DNS name, NetBIOS name, or IP address for machinename).
- Log in with the right account
Domain Time II Manager uses the credentials of the logged-in user to make network connections. Update Server and Audit Server run
as background services using the credentials specified in the Services database. Each program
must run under credentials with rights sufficient to make changes through connections to administrative shares and Remote Registry.
For Manager, be sure you are logged on as a user who has administrative rights on the remote machine. For Update Server and Audit Server,
verify that their service is set to start Automatically and set to Log On using an account with administrative rights to the remote machine(s).
Within a domain, members of the Domain Admins
group have administrative rights by default on all machines that are members of the domain. If the remote machine is
in a different domain, you must have an inter-domain trust in place, or be logged in using a username and password
that matches a username and password on the other domain that does have adminstrative rights.
If the target machine is not a domain member, you must make sure the machine's workgroup name matches the domain/workgroup name of your
Manager and/or Audit Server (Update Server will not work against target machines that are not domain members).
Then, use the local users administration function in Control Panel (or MMC snap-in, depending
on your OS version) to make sure that the account name being used on the machine running Domain Time
II Manager and or Audit Server is listed as being a remote adminstrator for the local machine, either by name or by inclusion in a named
group, such as Domain Admins. Note that Win9x machines must have user-level security enabled for this to work properly.
- Enable NetBT
Some machine discovery functions of Manager, Update Server and Audit Server use the Windows Network Browse list. This function typically
requires that NetBIOS over TCP (NetBT) be enabled. Check the WINS tab of your Network TCP/IP v4 properties to be sure NetBT is enabled.
- Be sure you can connect to and read/write through administrative file shares
Domain Time II Manager, Update Server, and/or Audit Server must be able to read and write files on target machines using Windows Networking. It does this
via UNC paths such as \\machinename\admin$\system32\.
Perform the following test to be sure the account you're using can access administrative shares. This example assumes you have a target
machine named FRED with an IP address of 10.1.1.23. Substitute your own test machine's name and IP address, of course.
- Log in to the machine where Manager, Update Server, and/or Audit Server will run using the administrative account that will be used to
run the program or service.
- Using Notepad, try to open \\FRED\Admin$\win.ini or \\10.1.1.23\Admin$\win.ini,
and, if you can open it, save the file.
- If you cannot open or save the win.ini file, you either do not have sufficient rights, file sharing isn't enabled,
or the special Admin$ share has been deleted. Check with your network administrator to
correct the problem.
Note: If your machine is running Vista or later and not a member of a domain (in a workgroup), network access to your administrative shares (i.e. admin$) is blocked by default.
Create the following registry entry to permit this:
Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Value: LocalAccountTokenFilterPolicy
Data: 1
You may also need to use Group Policy Editor (gpedit.msc) to verify the following policy setting:
Location: Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
Policy: Network access: Sharing and security model for local accounts
Data: Classic - local users authenticate as themselves
See File and Printer Sharing in Windows Vista or
Configure File and Printer Sharing for Microsoft Networks for more info.
- Make sure the Registry is accessible remotely on the target machines.
Check the Services database on your remote systems to be sure the Remote Registry service is set to Automatic and is started.
The Remote Registry Service is not installed by default on Win9x machines, and is turned off by default on many newer
operating systems so you will need to explicitly verify that this is operational.
Do the following test to be sure you can access the registry on your remote machines. As above, this example assumes you have a target
machine named FRED:
- Log in to the machine where Manager, Update Server, and/or Audit Server will run using the administrative account that will be used to
run the program or service.
- Start Regedt32.exe and use the Connect Remote Registry function to connect to \\FRED.
you can connect, try creating and then deleting a test key or value in HKEY_LOCAL_MACHINE on the remote system. If you
cannot, then check the policies and/or WinReg permissions. (See Microsoft's
KB314837 or
KB186433 for information on WinReg options.)
Note: If you're testing a connection from an earlier version of Windows to a more recent version, you may not be able to
actually create/delete a registry key due to regedt32 incompatibilities between versions. However, you should at least be
able verify that you can make the connection using RegEdt32, even if you can't open or write any keys.
|
See our complete catalog of software...
