Greyware Automation Products, Inc.
Greyware Automation Products, Inc.   
     Home    Products    Store    Downloads    Customer Service    Site Search    
Log in  or   Create an account now -- FREE!        
Kb > Knowledgebase Article KB2001.728

KB2001.728
Problem: '[Control] Access Denied' using Domain Time II Manager, Client, Server, Update Server, or Audit Server

    This article applies to Domain Time Domain Time II Manager, Domain Time II Update Server, and Domain Time II Audit Server

    Last updated: 9 March 2018

    Problem

      When you try to control a remote machine using Domain Time II Manager, you get "Control Access Denied" or "Access Denied" errors, and, on Manager Version 4.1 and earlier, all (or most) of the buttons on the Connected to... dialog window 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 "Access Denied" or "Logon Failure" errors, and on some versions, all (or most) of the control buttons will be grayed out.

      If Manager can determine that Domain Time II Client or Server is installed on the remote machine, but doesn't have sufficient permission to provide full remote control it will only enable the Sync Now, Reset Stats, and Refresh functions. 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 Client or Server
      The "Connect to another computer" function of the Domain Time applet also uses Microsoft Networking to provide display of settings on remote Domain Time Clients or Servers. As above, access will fail with insufficient permissions.

      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 use three tests to verify remote access permission:

      1. 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.

      2. File System
        The remote machine must allow you to connect to its ADMIN$ share and read/write files. The ADMIN$ and drive shares exists by default on machines joined to a domain as long as File and Print Sharing is installed and enabled. On newer versions of Windows, machines in workgroups need to have this capability enabled by a registry change (see #7 below).

      3. 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 XP and later 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:

      1. Use the right version for your processor architecture
        As of version 5.1, Domain Time Manager is capable of upgrading both 32-bit and 64-bit versions of Windows from a single installation.

        These considerations only apply to version 4.1 and earlier:

        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.

        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.

      2. 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.

      3. 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.

      4. 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).

      5. Log in with the right account
        Domain Time II Manager, Client, and Server initially use the credentials of the logged-in user to make remote network connections. If connection cannot be made using those credentials, you will be prompted to enter correct credentials. Use of logon credentials is controlled entirely by Windows; any errors are those provided by Windows in attempting the connection.

        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 or connecting 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.

      6. Enable NetBT
        As of version 5.1, discovery uses Active Directory and/or broadcasts/multicasts to discover machines. NetBT is still useful on workgroup members, but not normally required on domains.

        Some machine discovery functions of Manager, Update Server and Audit Server can also use the Windows Network Browse list to discover machines. 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. Also, more recent version of Windows (i.e. Windows 10) may need to have the SMB 1.0/CIFS File Sharing Support feature added for computer browsing to work.

      7. Be sure you can connect to and read/write through administrative file shares
        Domain Time II components must be able to read and write files on remote target machines using Windows Networking. They do 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, Client, Server, 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 not a member of a domain (in a workgroup), you need to disable Simple File Sharing. This is usually found on the list of Folder Options in Explorer (This option may be called Public File Sharing and controlled from the Network Sharing Center on newer versions).

        Also, if your workgroup machine is running Vista or later, 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.

      8. 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. If you can connect successfully, try creating and then deleting a test key or value in HKEY_LOCAL_MACHINE on the remote system. If you are unable to create a test key, check your registry's permissions to be sure there are sufficient rights for your account.

          If you cannot connect successfully to the remote registry, 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.

My Account  |   Contact Us  |   Feedback to Greyware  |   Privacy Policy  |   Printer-Friendly Version
 
Copyright © 1995-2019 Greyware Automation Products, Inc.  All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.