Testing and Troubleshooting a COM/DCOM Connection

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

• Make sure you observe COM/DCOM requirements:
  • You must use a SAS object server to test a DCOM connection. You cannot test a DCOM configuration by trying to attach to an object 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 un-trusted 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 usernames 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
    HKEY_CLASSES_ROOT\AppID\{440196D4-90F0-11D0-9F41-00A024BB830C}
    HKEY_CLASSES_ROOT\CLSID\{440196D4-90F0-11D0-9F41-00A024BB830C}\AppId (if it
    exists)
    

    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.

  • Rebooting after making dcomcnfg changes may be necessary.

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

• 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. There is no SCM on Windows 95/98, but Windows 95/98 can still launch a local SAS.

  • If you do not have a license for the Integration Technologies product, the IOM server restricts incoming connections by only allowing connections from the local machine. As part of this verification, the server 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, you should consider using the SAS Workspace Manager to initiate the client session.

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

  • A good technique to use to determine what userid 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 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 userid 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. For a C/C++ application, Microsoft suggests calling CoInitializeSecurity with an authenticationLevel of None. For a VB 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).

  • While Windows 95 can make calls at any authentication level, it can only receive calls if it is configured for a level of NONE or CONNECT. SAS does not support using Windows 95/98 as a server through DCOM.

• Make sure the impersonation levels are correct:
  • In order for impersonation to work, the dcomcnfg impersonation level must be set to impersonate AND the client authentication level must be set to connect or stronger. Otherwise, IServerSecurity ImpersonateClient() will return a failure.

  • On Windows 98 local COM, IServerSecurity ImpersonateClient() returns 0x80004001 (Not Implemented), regardless of the impersonation level.