Troubleshooting a COM/DCOM Connection

The following tips provide assistance for troubleshooting a COM/DCOM connection.

• Make sure you observe COM/DCOM requirements:
  • You must use a SAS server to test a DCOM connection. You cannot test a DCOM configuration by trying to connect to a server on the same machine. This type of connection uses COM instead.

  • To obtain details about why a DCOM connection attempt failed, check the System Log using the Event Viewer on NT (Start Programs Administrative Tools Event Viewer). Double click on an event that has a source of DCOM.

  • In order to get two machines working with DCOM across untrusted domains, the AuthenticationLevel must be set to NONE on both machines. However, if you do this, the impersonation of the client will fail. There is also a requirement that the user names and passwords must be identical in both domains. In this case, Authentication can be enabled.

  • To determine if launch permissions or access permissions need to be fixed, use the control panel to assign a sound to for starting and ending processes. If you hear the sound, launch permissions are probably OK, but access permissions need to be adjusted. If you don't hear a sound, check your launch permissions. This is necessary because the server process may come and go faster than the NT task manager can update.

• Make sure the registry settings are correct:
  • To reset application-specific dcomcnfg settings, edit the registry and remove the following keys:

    HKEY_CLASSES_ROOT\AppID\SAS.EXE     (if it exists)
    HKEY_CLASSES_ROOT\AppID\
            {440196D4-90F0-11D0-9F41-00A024BB830C}
    

    Run dcomcnfg and view the (empty) access and launch permissions. When you press OK or Apply, the dcomcnfg utility will put in some values for access and launch permissions. You can see those values by viewing the access and launch permissions again through dcomcnfg.

  • The Default security registry location is

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole
    

  • DCOM registry settings affect local COM also. DefaultAccessPermissions (recommend Interactive and System), DefaultLaunchPermissions (recommend Interactive and System), and Impersonation (recommend IMPERSONATE) are all important for local COM. If you need to run local COM without a license, set the authentication level to CONNECT.

  • Restart any affected server or client processes.

  • Individual registry keys can be secured with regedt32, but not regedit.

• Make sure the working directory is correct:
  • The current working directory for all programs (including SAS) started from the NT4 SCM is:

    c:\winnt\system32
    

    (This is the directory where rpcss.exe exists.) This means that files created by the SAS server (without a directory specified) will appear in this directory. To change the initial folder that is used after SAS starts, use the -sasinitialfolder option in your config file.

• Make sure the permissions are correct:
  • The NT Service Control Manager (SCM) runs in rpcss.exe. The SCM is responsible for launching SAS under both COM and DCOM.

  • If you do not have a license for the Integration Technologies product, the IOM server restricts incoming connections by allowing connections from the local machine only. As part of this verification, SAS System Version 8 servers must be able to impersonate the client. Because the SAS Workspace Manager will adjust the impersonation level settings when making a local connection to allow this check to work, if you are using Version 8 of the SAS System, then you should consider using the SAS Workspace Manager to initiate the client session. SAS System 9 and later servers can make this determination regardless of whether the client impersonation is enabled.

  • The system account must have launch and access permissions (the SCM runs under the system account).

  • A good technique to use to determine what user ID is being used to read/write files is to enable auditing on the file. To do this, first use the User Manager Policies Audit... to enable auditing for File and Object Access. At this point, nothing will actually be audited until the specific files that you want audited are enabled for auditing. Do this from the File Manager. Select Properties Security tab Auditing for each file you want to audit. (If you do this for a directory, you can specify all files under that directory.)

    To view the audited information, use the Event Viewer and select Log Security. This will show you what user ID attempted to access the files specified through the user manager.

  • An error message that states "Server execution failed" when trying to connect to the IOM server can be caused by many things including trying to connect to an IOM server with an expired license or having an invalid username/password in the dcomcnfg identity settings.

  • Events work by having the IOM server make a call on an interface that the client provides to SAS. In order for SAS to make a call on that interface, the client must grant permission to SAS to make the call.

    As another alternative, Microsoft has suggested setting the client's authentication level to None. For a C/C++ application, this can be controlled through CoInitializeSecurity. For a Visual Basic application, set the default authenticationLevel to None using dcomcnfg on the client side. Note that this implies that events cannot be encrypted, and that the only way to encrypt non-event data is through the server-side authenticationLevel settings in dcomcnfg.

• Make sure the authentication is correct:
  • On NT 4, the only authentication provided by default is NTLM, which uses RC4 for packet encryption (if you turn it on, of course).