Windows XP SP2, DCOM and ACAD 2Ki

Hello,

I have just upgraded my workstation to SP2 for Windows XP which runs
AutoCAD 2Ki for server-based automation. I have happily enjoyed over 4
years of problem-free operation, but now have an issue since installing
the latest Windows service pack. Currently, I have Windows 2000 and XP
workstations accessing my machine for remote automation.

Just for background, my program has been compiled for and has run on
NT4, 2000, and XP (pre-SP2), and with few exceptions, I have always
managed to be able to configure DCOM services for remote operation.
This is no longer the case. My configuration settings have not changed
since the upgrade to SP2, therefore one can only deduce that the
security "enhancements" provided in SP2 are blocking connectivity. My
logs state "the RPC server is unavailable," and making configuration
changes to DCOM (as limited as they are) do not resolve the issue. I
have full adminstrative priveleges for the server, and have ensured that
I am able to ping the client machines on the network.

Hopefully someone else may have encountered a similar problem when
upgrading to XP SP2 on a remote-automation AutoCAD workstation and can
direct me to the source of the problem, or better yet, a solution. If
all else fails, I either revert to SP1 or begin the migration of my
program to a current version AutoCAD. I prefer only to do the latter if
I am able to pinpoint the issue with the RPC server. Please, if anyone
has had remote automation killed with the latest XP service pack,
please contact me ASAP.

Additionally, if someone could pass this along to Tony Tanzillo, it
would be greatly appreciated.

Regards,
Eric

 

You didn't mention the Windows Firewall settings or whether you have already tried disabling it entirely. That said, DCOMconfig has indeed undergone changes in SP2, as has the default options for various services. There is a document on the MS web site that outlines the changes in SP2 that most often impact remote access, sharing and so forth. Check out http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx for more information.

 

In response to your suggestion for disabling the Windows firewall
entirely, dstein, in doing so, the client calls to the automation server
returned immediately (opposed to a 5+ second delay) with the same RPC
server failure. Communication also fails when the applications involved
are placed on the WF exclusions list and enabled. I have since reverted
to SP1 so that our department can go back to business as usual.

Digging into the docs, there are three facets of the security model
which are affecting remote automation. DCOM is still straightforward,
therefore I've not included it below.
1. RestrictRemoteClients registry key - this key can be implemented
through the MMC Group Policy snap-in, and has the following values:
(0) RPC_RESTRICT_REMOTE_CLIENT_NONE - implements the behavior of
previous Windows OS.
(1) RPC_RESTRICT_REMOTE_CLIENT_DEFAULT - restricts access to all RPC
interfaces, i.e. all remote anonymous calls to the RPC runtime are
rejected if an interface is not registered to accept them.
(2) RPC_RESTRICT_REMOTE_CLIENT_HIGH - all anonymous calls to the RPC
runtime are rejected, period.

**I have set this value to RPC_RESTRICT_REMOTE_CLIENT_NONE on the server
workstation with no success**

2. EnableAuthEpResolution registry key - this key can be implemented
through the MMC Group Policy snap-in on RPC clients and has the effect
that a RPC client runtime will use NTLM to authenticate to the Endpoint
Mapper interface. Otherwise, an anonymous call to the EM interface will
fail by default on SP2 due to the default value of the
RestrictRemoteClients key.

**The main client for remote automation is using Windows 2000. A second
client running XP SP2 failed with this key disabled**

3. RPC Interface Registration flags - there are three new registration
flags which RPC app developers use for securing an RPC interface.
(1) RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH - when registered, allows
unauthenticated calls before they reach the security callback.
Applicable only if a security callback is registered.
(1) RPC_IF_SEC_NO_CACHE - Enables/disables caching of a client's
security callbacks to an interface.
(1) RPC_IF_LOCAL_ONLY - Enables/disables rejection of calls made by
remote RPC clients.

This leads to the following questions:
A. How are the AutoCAD.* interfaces registered with Windows? Does it
use RpcServerRegisterIf? All I know is that I use regsvr32 to register
the type library on the client machines.
B. Are any of the AutoCAD.* interfaces registered using security callbacks?
C. Do I need to re-register the type library on my workstation after SP2
to accomodate the changes to the security model?
D. Can a Windows 2000 remote client access an XP SP2 RPC interface?
E. Will I have the same issues with remote automation using AutoACAD 2004?

The changes to SP2 has serious implications to the continued use of my
application. Due to migrating from Delphi to development on the Java
platform several years ago, I am not knowledgeable enough to
troubleshoot the Microsoft security issues at hand. At the time my app
was written, it required little experience of DCOM to configure my
system for remote clients to access the server, and therefore I do not
have an in-depth knowledge of RPC communication.

 

I neglected to provide an example of how I connnect to the automation
server. Here it is below.

try
CoInitialize(nil);
acApp := TAcadApplication.Create(FindControl(AppInfo^.MainFormHandle));
if AcadRemote or ForceRemote then
begin
acApp.ConnectKind := ckRemote;
acApp.RemoteMachineName := acDwgData^.RemoteSrv;
AcadLog.Log('ConnectAutoCAD: Connecting to remote AutoCAD server
on ' +
acDwgData^.RemoteSrv);
end;
acApp.Connect;
except
on E: Exception do
begin
ACADLog.Log('ConnectAutoCAD: An error occurred while connecting
to AutoCAD: ' +
E.Message);
raise;
end;