Skip to end of metadata
Go to start of metadata

General requirements

In order to successfully be able to use J-Interop with a remote Windows System there is a number of requirements that have to be meet. 

  • Running "Remoteregistry" service
  • Prevent the firewall from blocking the J-Interop traffic
  • Prevent the Windows User Account Contol (UAC) from interfering
  • Configure other permissions

Depending on which Version of Windows you are using, different steps have to be taken or have to be taken differently.

C-Ware has developed a Tool that allows us to do agentless compiance checks on remote Windows systems. For this we had to make sure this tool works on all Windows platforms. That's why we installed 18 VMs with different versions of Windows and tried to get our tool up and running with them. Depending on the service-packs there were quite some differences.

Doing this evaluation was a pretty time consuming task and Google allways brought me back to copies of the same tutorials. That's why I took the time to write this down and make it publically available. Hopingly this will help others get around the frustrating task of finding all of this out themselves.

Short summary of common problems

Operating System

J-Interop works on this Operating System

Firewall

Remoteregistry Service

Local Security permissions

User Account Control (UAC)

Registry keys permissions

Windows XP

Couldn't get it working yet

 

 

 

 

 

Windows XP SP1

Couldn't get it working yet

 

 

 

 

 

Windows XP SP2

(tick)

(error)

(tick)

(error)

N.A.

(tick)

Windows XP SP3

(tick)

(error)

(tick)

(error)

N.A.

(tick)

Windows Vista

(tick)

(error)

(error)

(tick)

(error)

(tick)

Windows Vista SP1

(tick)

(error)

(error)

(tick)

(error)

(tick)

Windows Vista SP2

(tick)

(error)

(error)

(tick)

(error)

(tick)

Windows 7

(tick)

(error)

(error)

(tick)

(error)

(error)

Windows 7 SP1

(tick)

(error)

(error)

(tick)

(error)

(error)

Windows Server 2003

Got no Installation of this :-(

 

 

 

 

 

Windows Server 2003 SP1

(tick)

(tick)

(tick)

(tick)

N.A.

(tick)

Windows Server 2003 SP2

(tick)

(tick)

(tick)

(tick)

N.A.

(tick)

Windows Server 2003 R2 (SP1)

(tick)

(tick)

(tick)

(tick)

N.A.

(tick)

Windows Server 2003 R2 SP2

(tick)

(tick)

(tick)

(tick)

N.A.

(tick)

Windows Server 2008 (SP1)

(tick)

(error)

(tick)

(tick)

(error)

(tick)

Windows Server 2008 SP2

(tick)

(error)

(tick)

(tick)

(error)

(tick)

Windows Server 2008 R2

(tick)

(error)

(tick)

(tick)

(error)

(error)

Windows Server 2008 R2 SP1

(tick)

(error)

(tick)

(tick)

(error)

(error)

(tick)

No changes needed

(error)

Action required

N.A.

Feature not available therefore no changes needed

Firewall related problems

As we are connecting to a remote system, the firewall of the remote system could be interfering with J-Interops communication. The following ports have to be available:

  • TCP 135: General RPC Port (When doing asynchron RPC call the service listening on this port will tell the client on which port the component servicing his request will be waiting on)
  • UDP 137: Netbios Name Resolution
  • UDP 138: Netbios Datagram Service
  • TCP 139: Netbios Session Service
  • TCP 445: SMB
  • TCP ???: When doing asynchron RPC calls the remote host dllhost.exe starts a "server" dealing with the request. The Port this service listens on can be dynamic therefore tricky to configure.

In order to open the DCOM ports there are two options:

  • Explicitly opening DCOM ports
  • Dynamically opening DCOM ports

Explicitly opening DCOM ports

If you don't like the DCOM system from opening any port and want to control which ports it should open, you can limit this port range by using dcomcnfg. This also makes it possible to explicitly open ports for DCOM communication. Otherwise the DCOM system will use any free port. You can see that there could be a problem with "explicitly opening DCOM ports" and "DCOM using any free Port", which would in effect result in disabling the Firewall:

  1. Start dcomcnfg. 
  2. Rightclick "Komponentendienste / Computer / Arbeitsplatz / Component Services / Computers / My Computer" and select "Eigenschaften / Properties".
  3. Select the tab "Standardprotokolle / Default Protocols".
  4. Select "Verbindungsorientiertes TCP/IP / Connection-oriented TCP/IP" and klick "Eigenschaften Properties".
  5. By klicking on the "Hinzufügen... / Add..." Button you can add one (or multiple) ranges of port. Don't keep this range to small. I would suggest giving dcom at least 20-40 Ports.
  6. "Ok" all of the windows away.
  7. You will have to reboot in order for these changes to take effect.

For the first 5 Entries all Windows versions allready have predefined Rules that can be activated:

  • TCP 135: Windows-Verwaltungsinstrumentation (DCOM eingehend) File and Printer Sharing (NB-Datagram-In)
  • UDP 137: Datei- und Druckerfreigabe (NB-Name eingehend) File and Printer Sharing (NB-Name-In)
  • UDP 138: Datei- und Druckerfreigabe (NB-Datagramm eingehend) File and Printer Sharing (NB-Session-In)
  • TCP 139: Datei- und Druckerfreigabe (NB-Sitzung eingehend) File and Printer Sharing (SMB-In)
  • TCP 445: Datei- und Druckerfreigabe (SMB eingehend) Windows Management Instrumentation (DCOM-In)

In order to make asynchronous requests (no matter if with a fixed or dynamic port) you have to actually add one rule to the firewall configuration manually. This is where most tutorials in the web recommend you to add a port-based rule opening Port 7000-7100. I would suggest a different approach. Not all versions of Windows allow you to define a port range in a firewall rule (actually Only "Windows Server 2008 R2" and newer on the server side and "Windows 7" and newer on the Client support providing a Port-Range. This would end with you having to define 20-100 individual rules. This is nothing I would like to do. 

You can however add ports from the commandline. So start a commandline (cmd) as Administrator and using the following command you could add a port range by calling the "add one port" in a for-loop:

FOR /L %I IN (9000,1,9100) DO netsh firewall add portopening TCP %I "DCOM dynamic Port %I"

As a result your Firewall config will be polluted with 100 new entries that all have about the same name.

Dynamically opening DCOM Ports

Alternatively you could allow a program to open ports. I found out that all asynchronous calles are all opened by a programm called the dllhost.exe. Therefore I created a program-based rule that opens all ports created by dllhost.exe or one of it's child processes. For this simply add the program: %SystemRoot%\System32\dllhost.exe as target program. The really cool thing about this approach is, that you don't even have to define a port range for DCOM at all.

Remoteregistry related problems

The "Remote-Registrierung / Remoteregisty" service is vital to being able to connect to a remote system. Usually this service is running on all Windows systems ... all except Windows Vista and Windows 7. So in order to be able to connect to a remote system, this service has to be running. If you also set it to be started "Automatic" the service will also start automatically the next time the system boots.

Local Security Permission related problems

This is a problem that is only related to Windows XP systems. Even if this configuration-option is present in all Windows operating-systems, only with Windows XP it is configured in a way that prevents J-Interop from working correctly.

"Netzwerkzugiff: Modell für gemeinsame Nutzung und Sicherheit für lokale KontenNetwork access: Sharing and security model for local accounts" ist set to: "Nur Gast - lokale Benutzer authentifizieren sich als GastGuest only: local users authenticate as Guest" per default. This has to be changed to "Klassisch - lokale Benutzer authentifizieren sich als sie selbstClassic: local users authenticate as themselves". If this is set to "Nur Gast / Guest only", all remotely logged-in users have only guest permissions on the target system. This is rather undesirable.

User Account Control (UAC) related problems

Starting with Windows Vista and Windows Server 2008 Microsoft introduces the User Account Control (UAC). As a lot of users on Windows clients access their computers with Administrator accounts. This usually enables any Program execute any program or change any operating-system option. In order to prevent unwanted mmodifications, Microsoft introduced the UAC which Separates the Admin Account login from actual Admin tasks. In order to actually perform an Admin task, the operating-system now requests permission by displaying a popup. 

This new behaviour unfortunately breaks most functionality that J-Interop would execute, as with a non interactive session there is no way to display and click on a button in a popup and therefore the operating system dispatches a "permission denied". There are however some options to make it Possible to connect: 

  1. Login using the built in local Administrator account (Not a domain Admin account ... only the built in one works and you will probably have to enable this account first and set a password for it as it is usually disabled per default)
  2. Turn off UAC entirely
  3. Change the local security policy to disable Admin Approval Mode for administrators 

Activating the local Administrator account

  1. Start lusrmgr.msc
  2. Select "Lokale Benutzer und Gruppen / Benutzer / Local Users and Groups / Users
  3. Right-Click on the Administrator account and select "Eigenschaften / Properties"
  4. Unselect the "Konto ist deaktiviert / Account is disabled" checkbox
  5. Save with Ok
  6. Right-Click on the Administrator account again and select "Kennwort festlegen... / Set Password..."
  7. Confirm the warning
  8. Enter the new password twice
  9. Set/Change the password with Ok

Turn off UAC

  1. Open "Systemsteuerung / Benutzerkonten / Control Panel / User Accounts"
  2. Click on "Benutzerkontensteuerung ein- oder ausschalten / Turn User Account Control on or off"
  3. Depending on your Operating System:
    1. Windows Vista, Windows 2008: Disable the checkbox "Benutzerkontensteuerung verwenden, um zum Schutz des Computers beizutragen / User User Account Control (UAC) to help protect your computer" (It seems that on Windows Vista and Windows Server 2008 the UAC Checkbox is directly linked to the Admin Approval Mode selection in the Local Security Policy so on Windows Vista and Windows Server 2008 ?"Turn off UAC" and "Disable Admin Approval Mode for Administrators is identical".
    2. Windows 7, Windows 2008 R2: Here we have a slider and can select multiple levels. Here the slider has to be slided down to the bottom, completely disabling UAC
  4. Click on Ok
  5. Reboot

Disable Admin Approval Mode for administrators

  1. Start secpol.msc
  2. Select "Sicherheitseinstellungen / Lokale Richtlinien / Sicherheitsoptionen / Security Settings / Local Policies / Security Options"
  3. Right-Click the list Entry "Benutzerkontensteuerung: Alle Administratoren im Administratorbestätigungsmodus ausführen / User Account Control: run all administrators in Admin Approval mode" and select "Eigenschaften Properties"
  4. Select "Deaktiviert Disabled"
  5. Confirm with Ok
  6. Reboot the machine for the changed to take effect

 

INFO

When turning off the Admin Approval Mode for administrators, Windows will show the UAC as disabled in the UAC Control. I have checked the different settings in the local security policy and on Windows 2008 R2 and Windows 7 there is a great difference between turning off UAC and turing off the Admin Approval Mode for administators as all other UAC settings in the Local Security Policy still stay unchanged. It is only on Windows Vista and Windows Server 2008 that there is no difference at all between the two options. So don't be confused.

Registry Key permission related problems

It seems that in order to be able to use an OLE/COM component remotely, an "AppID" key has to be added in that objects registry entry. Usually JInterop does this automatically when using "JISystem.setAutoRegisteration(true)" in code.

Starting with Windwos 7 and Windows Server 2008 R2 most of these registry keys have the "TrustedInstaller" set as owner and only that user has full access to them. When JInterop now tries to make them remoteable by adding the AppID key, windows throws an error back at JInterop.

There are several ways to solve this problem:

  • Give the user JInterop is accessing the system full permissions to that particular key
  • Manually add the AppID to the ole objects registry and hereby manually do what JInterop intends to do automatically

In my particular case, I needed access to the following Objects:

  • Scripting.FileSystemObject: HKCR/CLSID/{0D43FE01-F093-11CF-8940-00A0C9054228}
  • WScript.Shell: HKCR/CLSID/{72C24DD5-D70A-438B-8A42-98424B88AFB8}
  • WBEM Scripting Locator: HKCR/CLSID/{76A64158-CB41-11D1-8B02-00600806D9B6} 

More information on this is found in the JInterop FAQ: http://www.j-interop.org/faq.html#A6

Give the user JInterop is accessing the system full permissions

In order to perform the changes you have do the following for every one of the above keys:

  1. Execute "regedit" in order to start the registry editor
  2. First select the key (using the search helps)
  3. Right-click the key and select "Berechtigungen... / Permissions ..."
  4. Currently only the owner is allowed to change the permissions and currently this owner is the "TrustedInstaller" user. Therefore we have to change the ownership first. In order to do so, click on "Erweitert / Advanced"
  5. Select the tab "Besitzer Owner"
  6. Select "Administratoren (.........) / Administrators (.........)"
  7. Click on Ok
  8. In order to make the ownership change effective, you have to commit the changes by klicking on Ok first and then reopening the Permissions dialog
  9. In the reopened Permissions dialog, add or select the user or group you want to access the system under and select the checkbox for allowing "Vollzugriff / Full Control"
  10. Click on Ok
  11. Right-click the key a third time and select "Berechtigungen... / Permissions ..."
  12. Click on "Erweitert / Advanced"
  13. Select the tab "Besitzer Owner"
  14. Click on "Weitere Benutzer oder Gruppen / "
  15. Enter the following username (you can't select it from any list) "NT Service\TrustedInstaller"
  16. Click on Ok
  17. Click on Ok
  18. Repeat this procedure for each of the other keys.

Manually add the AppId to the OLE objects registry

  1. Search for the OLE objects registry entry (HKCR/CLSID/{uuid})
  2. Create an AppID (REG_SZ) value inside that entry and set that to the same Id as the UUID of the component
  3. After this add a new key to HKCR/AppID (HKCR/AppID/{uuid})
  4. Inside this new key, simply add two keys:
    • "(Sandard) / (Default)" (REG_SZ) (The braces are important): Give it a sensible name describing what the object actually is (This is then the name you can find the component under when configuring the compoent using dcomcnfg.
    • DllSurrogate (REG_SZ): (this can be left empty)

Server Operating Systems

In order to document the configuration changes, I installed clean versions of the operating systems, cloned them and applied different service packs. I intentionally prevented updates from being installed. Starting with these clean installations I tried to get my J-Interop based application running with these systems and documented them in the following chapters for every system.

Windows Server 2003 (04.2003)

Unfortunately I didn't have an installation of Windows 2003 I could test on, but I would assume the same applies to Windows Server 2003 as does with Windows Server 2003 SP1.

Windows Server 2003 SP1 (03.2005)

No cconfiguration changes were needed.

Windows Server 2003 SP2 (03.2007)

No cconfiguration changes were needed.

Windows Server 2003 R2 (02.2006) (Includes SP1)

No cconfiguration changes were needed.

Windows Server 2003 SP2 (03.2007)

No cconfiguration changes were needed.

Windows Server 2008 SP1 (02.2008)

Windows Server 2008 was the first Microsoft Server operating system to be shipped with a firewall, so this has to be configured prior to be able to connect to it. See the chapter "Firewall related problems" for more information on that.

It was also the first Server product that included Microsofts User Account Control (UAC) so this is interfering too. See the chapter "User Account Control (UAC) related problems" for more information.

But afer choosing a solution for the firewall and UAC problems, connection works without any problems.

Windows Server 2008 SP2 (04.2009)

Windows Server 2008 SP2 seems to be cconfigured identically to Windows Server 2008 SP1 so please follow the guide for that system.

Windows Server 2008 R2 (10.2009)

Windows Server 2008 R2 ist configured allmost identiallly to Windows 2008 SP1, so please follow the firewall and UAC configuration guide of that system. 

One difference however is how the User Account Control is disabled. Instead of a Checkbox in this case there is a slider. In order to turn off the UAC, just drag the Slider to the bottom. After rebooting UAC should be disabled.

The biggest differences however are small changes in the permissions of the systems registry. See the chapter on "Registry Key permissions related problems"

After these changes the connection should work with Windows Server 2008 R2.

Windows Server 2008 R2 SP1 (03.2010)

Windows Server 2008 SP2 SP1 seems to be cconfigured identically to Windows Server 2008 R2 so please follow the guide for that system.

Client Operating Systems

Windows XP (10.2001)

Unfortunately I haven't been able to connect to a Windows XP without any installed service pack.

Windows XP SP1 (08.2002) 32bit

Unfortunately I haven't been able to connect to a Windows XP SP1.

Windows XP SP2 (09.2004) 32bit

All Microsoft client operating systems starting with Windows XP SP2 and later were shipped with a firewall. This is blocking allmost all inbound traffic. See the chapter "Firewall related problems" for more information on that.

After the Firewall is configured on Windows XP systems some Local Security Policy settings have to be changed, or JInterop will not be able to connect. See the chapter "Local Security Policy related problems" for more information on how to resolve that problem.

Now the system should be accessible.

Windows XP SP3 (04.2008) 32bit

Windows XP SP3 seems to be cconfigured identically to Windows XP SP2 so please follow the guide for that system.

Windows Vista (01.2007) 32 bit

Starting with Windows Vista the client operating systems have the Remoteregistry Service discbled per default. Therefore check the chapter "Remoteregistry related problems" on how to fix this.

As with Windows XP the Firewall has to be configured. See the chapter "Firewall related problems" for more information on that.

Last but not least Vista introduced the User Account Control (UAC) this is causing major trouble when connecting to a remote Vista system. So check the chapter "User Account Control (UAC) related problems".

Now the system should be accessible.

Windows Vista SP1 (02.2008) 64bit

Windows Vista SP1 seems to be cconfigured identically to Windows Vista so please follow the guide for that system.

Windows Vista SP2 (05.2009) 64bit

Windows Vista SP2 seems to be cconfigured identically to Windows Vista so please follow the guide for that system.

Windows 7 (10.2009) 64bit

In order to have Windows 7 accessible the same steps have to be done as with Windows Vista: Configure the Firewall, start the Remoteregistry service and configure the User Account Control (UAC).

Unfortunatley there were also some changes with permissions in the Registry. These are preventing JInterop from correctly functioning. Therefore look at the chapter "Registry Key permission related problems"

Now the system should be accessible.

Windows 7 SP1 (02.2011) 64bit

Windows 7 SP1 verhält sich identisch zu Windows 7, befolgen Sie daher bitte die Anleitung von Windows 7.

Links

http://www.poweradmin.com/help/enableWMI.aspx (Enable WMI (Windows Management Instrumentation)

http://msdn.microsoft.com/en-us/library/Aa393266.aspx (Securing a Remote WMI Connection)

http://msdn.microsoft.com/en-us/library/windows/desktop/aa826699(v=vs.85).aspx (User Account Control and WMI)

http://community.spiceworks.com/topic/5612-bulk-enable-dcom

http://www.gmusoft.de/information/windows/WindowsPowerShell.htm (Verwenden der PowerShel)

  • No labels