Quest



Contents TOC \o "1-3" \h \z \u WMI Connectivity Troubleshooting PAGEREF _Toc239699673 \h 2Troubleshooting Sequence PAGEREF _Toc239699674 \h 2Pre Requisites PAGEREF _Toc239699675 \h 3DCOM Impersonation and Authentication Settings PAGEREF _Toc239699676 \h 3COM Security Settings PAGEREF _Toc239699677 \h 4WMI Control Settings PAGEREF _Toc239699678 \h 4Firewall Exceptions PAGEREF _Toc239699679 \h 5Running WMI Diagnosis Utility PAGEREF _Toc239699680 \h 5Microsoft utilities to test WMI connectivity PAGEREF _Toc239699681 \h 6Connecting to XP / Windows 2003 behind Windows Firewall PAGEREF _Toc239699682 \h 6To configure Connection 1 PAGEREF _Toc239699683 \h 6Connecting to Vista / Windows 2008 and above behind Windows Firewall PAGEREF _Toc239699684 \h 7To enable or disable WMI traffic using firewall UI PAGEREF _Toc239699685 \h 7To enable or disable WMI traffic at command prompt using WMI rule group PAGEREF _Toc239699686 \h 7Some common error scenarios PAGEREF _Toc239699687 \h 8Error message [0x80041003]: The current user does not have permission to perform the action PAGEREF _Toc239699688 \h 8Error message [0x80070005]: Access is denied PAGEREF _Toc239699689 \h 9Error message [0x800706BA]: The RPC server is unavailable PAGEREF _Toc239699690 \h 12Troubleshooting remote errors PAGEREF _Toc239699691 \h 13Enabling Account privileges in WMI PAGEREF _Toc239699692 \h 14Monitoring remote targets in local WORKGROUP (Vista / Windows 2008) PAGEREF _Toc239699693 \h 14Common errors encountered while connecting to WMI from a remote machine PAGEREF _Toc239699694 \h 15Useful web links PAGEREF _Toc239699695 \h 16Links related to WMI Configuration PAGEREF _Toc239699696 \h 16Links related to WMI troubleshooting PAGEREF _Toc239699697 \h 16Test scenarios we need to test out PAGEREF _Toc239699698 \h 16WMI Connectivity TroubleshootingTroubleshooting SequenceWhen an organization reports WMI connectivity issue through our application, the first thing to do is to test the connectivity issue outside our product environment thru’ the wbemtest (Windows Management Instrumentation Tester) utility. This is a utility that comes part of the operating system and has to be run from the DOS console on the machine from which WMI connection is being attempted. When WMI connectivity thru the wbemtest utility fails, the connectivity from the product would always fail. I am yet to see an instance when wbemtest succeeds and our application fails to connect. It would be safe to ignore this scenario.For our product to work correctly, we need access to the following namespaces.\\server_ip\root \\server_ip\root\default\\server_ip\root\cimv2Replace server_ip with the ip address of the target host. Avoid using NETBIOS names.The user name in the ‘Connect’ dialog of ‘wbemtest’ should be in the format ‘Domain_Name\User_Name’. Give the appropriate password and leave the Authority & LOCALE fields as BLANK. Set the ‘Impersonation Level’ as ‘Impersonate’ and Authentication Level as ‘Packet’.Each namespace has to be connected independently. Note down the error number (it would be a hexadecimal number) that wbemtest tool reports when connection attempts fail.Next, refer to the section ‘Pre Requisites’ in the ‘WMI Troubleshooting Tips.docx’. All the mention pre requisites have to be fulfilled for the connectivity to go through. Important links that would help us in understanding the configuration needs are as followsDescriptionURLConnecting to WMI on a Remote Computer (Windows)(VS.85).aspxWMI Service Log Files (Windows)(VS.85).aspxConnecting thru Windows Firewall(VS.85).aspxConnecting to WMI Remotely starting with Windows Vista(VS.85).aspxSecuring a remote WMI connection (has details on DCOM configuration entries. Very important link)(VS.85).aspxUsing Distributed COM with Firewalls, refer to the section ‘Some common error scenarios’. If the error number falls in the list mentioned in the document, apply the fixes as mentioned and try connecting thru’ wbemtest again.If the mentioned fixes do not help solve the problem, the following steps should be tried out.Microsoft provides a script called WMIDiag.vbs that can be used to analyze the WMI readiness of a specific target to allow successful inbound WMI connections. Refer to the section ‘Running WMI Diagnosis Utility’. The organization should try out the suggestions mentioned in the document to rectify the connectivity issue. Request the organization to pass on these output files to us as well for our analysis as well.If the diagnosis script does not help in solving the problem, we need to trace the wmi calls on the host and the target. Refer to the section ‘Troubleshooting Remote errors’. The organization has to send the files in the directory %windir%\system32\wbem\logs.Pre RequisitesWMI works in conjunction with RPC and DCOM. TCP ports 135 and 445 must be available on the target machines to get WMI connection is being attempted.Services Remote Procedure Call (RPC), Windows Management Instrumentation (WMI) and DCOM Server Process Launcher (DcomLaunch) should be running. Preferably, the startup type of these services should be set as ‘Automatic’.DCOM should be enabled. Verify the following registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\EnableDCOM” should have the value “Y”DCOM Impersonation and Authentication SettingsWMI has default DCOM impersonation, authentication, and authentication service (NTLM or Kerberos) settings that the target computer (Computer B) in a remote connection puter B operating system Impersonation level scripting stringAuthentication level scripting stringAuthentication service Windows?2000 (WMI 1.5)ImpersonateConnectKerberosWindows?XP ProfessionalImpersonatePktKerberosWindows Server?2003ImpersonatePktKerberosWindows?VistaImpersonatePktKerberosThe following GUI can be reached by typing ‘dcomcnfg’ in the Start Run command boxCOM Security SettingsChoose the ‘COM Security’ TAB as mentioned in the previous screenshotClick ‘Edit Limits’ button in the ‘Launch and Activate Permissions’ groupbox.Add the user name that would be used for WMI connection in the ‘Group or user names’ list boxFor this user, in the ‘Permissions for Everyone’ listbox, enable the Local Launch, Remote Launch, Local Activation and Remote Activation permissions.WMI Control SettingsWMI Control can be reached from Computer Management -> Services and Applications -> WMI ControlWe need to set up the appropriate permissions for three namespaces viz. root root\DEFAULT root\cimv2Right click WMI Control and navigate to the Properties menu. Choose the Security TAB.Highlight Root and click Security button. In the Groups or User Names listbox, add the user name that would be used to establish WMI connection to this machine. For this user, the following permissions should be set in the ‘Permissions for Authenticated Users’ groupbox in the Security tab.Enable AccountRemote EnableClick the Advanced button. Choose the appropriate user and click Edit button. In the Apply To combo box, choose ‘This namespace and subnamespaces’. Click Ok and close Advanced Security settings.Expand Root and navigate to the DEFAULT namespace. Highlight DEFAULT and click Security button. As done for the root namespace, assign the ‘Enable Account’ and ‘Remote Enable’ permissions for root\DEFAULT namespaceExpand Root and navigate to the cimv2 namespace. Highlight cimv2 and click Security button. As done for the root namespace, assign the ‘Enable Account’ and ‘Remote Enable’ permissions for root\cimv2 namespaceFirewall ExceptionsFire the following command to allow WMI connection requests to filter thru the firewallnetsh firewall set service type=remoteadmin mode=enableIf firewall is ON and if the above exception is not added, error 0x800706ba would pop up.Running WMI Diagnosis UtilityThe following steps should be implemented on the machine to which WMI connectivity has to be establishedDownload the utility from the following URL the download should generate a VB script file named WMIDiag.vbsOpen a command prompt and run the command “cscript WMIDiag.vbs”The process should generate a report in .txt format and also generate additional log files as mentioned in the report document.Please inspect the document for inconsistencies in the WMI configuration and rectify the same.After rectifying the configuration, run the script WMIDiag.vbs again to confirm that the WMI settings are in order.Microsoft utilities to test WMI connectivityDownload WMI Tools from the following URL WMI CIM Studio under WMI Tools to test connectivity to remote targetsNote: WMI CIM Studio can be run effectively only from within IE browser. It relies on ActiveX controls that work best under IE. Alternatively, we can use WBEMTest, that ships with the operating system and can be started from Start -> Run -> wbemtestIf WMI connectivity cannot be established thru either of these tools, the infrastructure problem needs to be fixed using the log output obtained by running WMIDiag.vbsConnecting to XP / Windows 2003 behind Windows Firewall((VS.85).aspx)When obtaining data from a remote computer, WMI must establish a DCOM connection from Computer A (the local computer) to Computer B (the remote computer)—this is shown in the diagram as Connection 1. To establish this connection, both Windows Firewall and DCOM on Computer B must be configured appropriately. The configuration must be done locally on Computer B either by changing the Group Policy settings, by executing NETSH commands, or by executing a script locally. Windows Firewall does not support any remote configuration.The following diagram shows the relationship of WMI, the Windows Firewall, and DCOM when a script or another WMI client makes an asynchronous call to obtain data from WMI. Synchronous and semisynchronous calls only make Connection 1. Connection 2 occurs only with asynchronous calls. If the script or application made an asynchronous call, Connection 2 from Computer B to Computer A delivers the results. This delivery is the callback to the sink. When possible, semisynchronous calls should be made instead of asynchronous calls. The performance of semisynchronous calls is almost as good as asynchronous calls and semisynchronous calls are more secure.To configure Connection 1Ensure that the user account that is on Computer A is a local administrator on Computer B.If the user account that is on Computer A is not an administrator on Computer B, but the user account has Remote Enable permission on Computer B, then the user must also be given DCOM Remote Launch and Remote Activation privileges on Computer B by running Dcomcnfg.exe at the command prompt. For more information, see the remote launch and activation permissions procedure in Securing a Remote WMI Connection. The 0x80070005 error occurs when this privilege is not set. For more information, see Access to WMI Namespaces.Allow for remote administration on Computer B. You can use either the Group Policy editor (Gpedit.msc) or a script to enable the Windows Firewall: Allow remote administration exception, or use a netsh firewall command at the command prompt to allow for remote administration on Computer B. The following command enables this sh firewall set service RemoteAdmin enableIf you would rather use the Group Policy editor than the NETSH commands above, use the following steps in the Group Policy editor (Gpedit.msc) to enable "Allow Remote Administration" on Computer B. Under the Local Computer Policy heading, double-click Computer Configuration.Double-click Administrative Templates, Network, Network Connections, and then Windows Firewall.If the computer is in the domain, then double-click Domain Profile; otherwise, double-click Standard Profile.Click Windows Firewall: Allow remote administration exception.On the Action menu, select Properties.Click Enable, and then click OK.Connecting to Vista / Windows 2008 and above behind Windows Firewall((VS.85).aspx)To enable or disable WMI traffic using firewall UIIn the Control Panel, click Security and then click Windows Firewall.Click Change Settings and then click the Exceptions tab.In the Exceptions window, select the check box for Windows Management Instrumentation (WMI) to enable WMI traffic through the firewall. To disable WMI traffic, clear the check box.To enable or disable WMI traffic at command prompt using WMI rule groupUse the following commands at a command prompt. Type the following to enable WMI traffic through the firewall. netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yesType the following command to disable WMI traffic through the firewall. netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=noSome common error scenariosError message [0x80041003]: The current user does not have permission to perform the actionError 0x80041003 implies WBEM_E_ACCESS_DENIEDThis typically results when the process trying to access the namespace does not have the required WMI privileges. The account attempting remote access should be an administrator on the target computer; in addition, the account might need to have a specific privilege enabled. To troubleshoot this error, check the namespace security on the remote namespace to see the privileges enabled for the account.Sample scenarios when this error can come about'Access is denied' for \\root namespace when 'Remote Enable' permission is disabled for \\root namespace in WMI control properties under Computer Management\Services and Applications\WMI Control'Access is denied' for \\root\DEFAULT namespace when 'Remote Enable' permission is disabled for \\root\DEFAULT namespace in WMI control properties under Computer Management\Services and Applications\WMI Control'Access is denied' for \\root\cimv2 namespace when 'Remote Enable' permission is disabled for \\root\cimv2 namespace in WMI control properties under Computer Management\Services and Applications\WMI ControlSecurity configuration to bypass 0x80041003You can access the WMI Control and the Security tab in the Computer Management Console: Right-click on My Computer and click Manage.Double-click Services and Applications and then double-click WMI Control.Right-click WMI Control and then click Properties.In the WMI Control Properties dialog box click the Security tab.A folder named Root with a plus sign (+) next to it should now be visible. Expand this tree as necessary to locate the namespace CIMV2.Click the Security button. A list of users and their permissions appears. If the user is on that list modify the permissions as appropriate. Add "network service" account (from local computer accounts) and administrator account. If the user is not on the list, click the Add button, and add the user from the location (local machine, domain, etc.) where the account resides.In order to view and set namespace security, the user must have Read Security and Edit Security permissions. Administrators have these permissions by default, and can assign the permissions to other user accounts as required.If this user needs to access the namespace remotely, you must select the Remote Enable permission.By default, user permissions set on a namespace apply only to that namespace. If you want the user to have access to that namespace and all sub namespaces in the tree below it, or in sub namespaces only, click the Advanced button. Click Edit and specify the scope of access in the resulting dialog box.Error message [0x80070005]: Access is deniedError 0x80070005 implies DCOM ACCESS_DENIEDThis error occurs when the connected user is not recognized or is restricted in some fashion by the remote server (for example, the user might be locked out). This happens most often when accounts are in different domains. Recent changes to WMI security can also cause this error to occur:?Blank passwords, formerly permitted, are not allowed in Windows XP and Windows Server 2003.?WMI does not allow asynchronous callbacks to a Windows 98 client. A call like SWbemServices.ExecNotificationQueryAsync from a Windows 98 computer to a Windows XP computer will result in an Access Denied error returned to the Windows 98 machine.?The DCOM configuration access setting might have been changed. ?If the target computer is running Windows XP, the Forceguest value under the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa might be set to force the Guest account off (value is zero). This error would come when DCOM security is configured as mentioned below'Access is denied' for \\root namespace or \\root\default namespace or \\root\cimv2 namespace when 'Remote Activation' permission in DCOM Config --> COM Security --> Launch Activation Permissions --> Edit Limits is uncheckedSecurity configuration to bypass 0x80070005Click Start, click Run, type DCOMCNFG, and then click OK.In the Component Services dialog box, expand Component Services, expand Computers, and then expand My Computer.On the toolbar, click the Configure My Computer button. The My Computer dialog box appears.In the My Computer dialog box, click the COM Security tab.Under Launch and Activate Permissions, click Edit Limits.In the Launch Permission dialog box, follow these steps if your name or your group does not appear in the Groups or user names list: In the Launch Permission dialog box, click Add. In the Select Users, Computers, or Groups dialog box, add your name and the group in the Enter the object names to select box and then click OK.In the Launch Permission dialog box, select your user and group in the Group or user names box. In the Allow column under Permissions for User, select Remote Launch, and then click OK.Miscellaneous checklist for ACCESS_DENIED errorThe user account used to connect to the remote machine must have administrative rights. The password for that user account should be non NULLVerify whether wbemtest utility allows to connect to the remote target with appropriate credentials. If connectivity thru wbemtest fails, the connectivity configuration has to be fixed and ensured that wbemtest works without errors. If not able to connect thru wbemtest, the NMS software also would also not be able to connect to remote target thru WMI.Verify whether WMI permissions have been set appropriately. The account used for reading must have full read rights on the root WMI namespace. If the target system is running Vista / Windows 2008, the machine is part of a local WORKGROUP and if UAC is enabled ON on the Vista / Windows 2008 system, wbemtest would report (‘Access is denied’ with error number 0x80070005). The solution for this scenario would be disable UAC when the machine is part of a local WORKGROUP.For Windows XP Professional operating system, verify that remote logins are not being coerced to the GUEST account - by having the ForceGuest option enabled (this is the default on systems, which are not connected to a domain). The steps you have to complete to verify this are:a. Open the Local Security Policy editor.b. Expand Local Policies and select Security Options.c. Find the setting named Network access: Sharing and security model for local accounts and verify that the value is not Guest Only. If this is the case, chance the value to Classic - and restart the computer.If system is behind a firewall, to verify DCOM settings to work behind firewall, refer the following URL (Using Distributed COM with Firewalls) (How to configure RPC dynamic port allocation to work with firewalls)Tweak the DCOM configuration for WMI through the following stepsLaunch dcomcnfgExpand Component ServicesExpand ComputersExpand My ComputerExpand DCOM ConfigNavigate to Windows Management and Instrumentation Right click and choose propertiesConfigure the Authentication level in the General TAB. (Preferably PACKET level authentication)In the Location TAB, the option ‘Run application on this computer’ should be checkedIn the Security TAB, under the ‘Launch and Activation permission’ group box, enable the Customize option. Click the edit button and ensure that the login used for WMI connection is listed in the user names list. Also ensure that the relevant user has all the options checked (Local Launch, Remote Launch, Local Activation, Remote Activation. Start with enabling Remote Launch and Remote Activation and if the connectivity works, leave it there)In the Security TAB, under the ‘Access permissions’ group box, enable the Customize option. Click the edit button and ensure that the login used for WMI connection is listed in the users list. Also ensure that the user has all the options checked (Local Access, Remote Access)If DCOM settings are modified, restart the machine for the settings to take effectVerify WMI connectivity thru wbemtest.Error message [0x800706BA]: The RPC server is unavailableError numbers in the range 0x800706xx implies DCOM RPC error.This often occurs when a firewall is configured on the remote computer. You will need to open the appropriate ports on the firewall to permit remote administration using DCOM.Alternatively, the computer might be having problems mapping the IP and the Hostname. To test that possibility, try using the IP address instead of the Hostname in your connection string:Please check the DCOM & firewall configuration on XP or Windows 2003 or Vista as described earlier.If firewall is ON, the error ‘The RPC Server is unavailable’ with the error number 0x800706ba may pop up.Fire the following command at the DOS prompt to allow connection requests bypass firewall netsh firewall set service type=remoteadmin mode=enableand test the connectivity again with wbemtest utility.Troubleshooting remote errors1.Check whether the user has access to the remote computer. From the command prompt, execute the following command:net user \\<remotecomputer>\\C$ /u:<domain\username> *2.Enable the verbose logging level on the remote computer and try connecting thru wbemtest. After running wbemtest, examine the logs on the remote machine (%windir%\system32\wbem\Logs\). Refer the following links for more details on enabling WMI logging(VS.85).aspx(WS.10).aspx audit events (thru Control Panel Administrative Tools Local Security Policy) to determine which account is responsible for the failed connection. After auditing has been enabled, you will see events similar to this in the event log:Event Type:????Failure AuditEvent Source:????SecurityEvent Category:????Logon/Logoff Event ID:????529Date:????????6/14/2004Time:????????10:52:35 AMUser:????????NT AUTHORITY\SYSTEMComputer:????<remote machine>Description:Logon Failure:?????Reason:????????Unknown user name or bad password?????User Name:????xuser?????Domain:????????NTDEV?????Logon Type:????3?????Logon Process:????NtLmSsp ?????Authentication Package:????MICROSOFT_AUTHENTICATION_PACKAGE_V1_0?????Workstation Name:????<console Machine >4.Check the DCOM configuration for the Access\Launch permission; the user running the script must have this permission. 5.If all the previous checks are OK, if the user is recognized by the remote computer, and if the connection still fails with a DCOM Access Denied error, provide the following details?The operating system each computer is running. ?The installation history ?The user credentials used to make the WMI connection, including the authentication and impersonation levels. ?A zip file of %windir%\system32\wbem\logs from both client computer and the target computerEnabling Account privileges in WMI1. Log on to the computer you want to monitor with an administrator account. 2. Navigate to Start > Control Panel > Administrative Tools > Computer Management > Services and Applications. You need to switch to the Classic View of the Control Panel to use this navigation path. 3. Click WMI Control, and then right-click and select Properties. 4. Select the Security tab, and then expand Root and click CIMV2. 5. Click Security and then select the user account used to access this computer and ensure you grant the following permissions: Enable Account Remote Enable 6. Click Advanced, and then select the user account used to access this computer. 7. Click Edit, select This namespace and subnamespaces in the Apply to field, and then click OK. 8. Click OK on the Advanced Security Settings for CIMV2 window. 9. Click OK on the Security for Root\CIMV2 window. 10. Repeat steps 4 thru 9, but choose the namespace ‘DEFAULT’ under Root. Similarly, repeat steps 4 thru 9 for the ‘Root’ namespace.11. Click Services in the left navigation pane of Computer Management. 12. Select Windows Management Instrumentation in the Services result pane, and then click Restart.Monitoring remote targets in local WORKGROUP (Vista / Windows 2008)If you are monitoring a target in a workgroup, you need to disable remote User Account Control (UAC). This is not recommended, but it is necessary when monitoring a workgroup computer. Disabling remote user account control does not disable local user account control functionality. Warning: The following procedure requires the modification or creation of a registry key. Changing the registry can have adverse effects on your computer and may result in an unbootable system. Consider backing up your registry before making these changes. To disable remote UAC for a workgroup computer: 1. Log on to the computer you want to monitor with an administrator account. 2. Click Start > Accessories > Command Prompt. 3. Enter regedit. 4. Expand HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. 5. Locate or create a DWORD entry named LocalAccountTokenFilterPolicy and provide a DWORD value of 1. Note: To re-enable remote UAC, change this value to 0Common errors encountered while connecting to WMI from a remote machineReturn Code:0x800700050x800706ba0x080041003Meaning:DCOM Access DeniedRPC Server UnavailableWMI Access DeniedDuring Connecting to a WMI namespace The Username/Password does not existThe user does not have the remote launch or remote activation options set. Check dcomcnfg.exe?The Machine does not existThe Machine cannot respond because the appropriate firewall exceptions have not been made. Check the firewall settings.The user does not have the appropriate WMI permission on a namespace.?During OperationThe specific user does not have the DCOM permissions.Minimum authentication level needed for the namespace is more than what is used.?The client machine doesn’t have correct firewall settings for asynchronous callbacks.Connecting to a machine which doesn’t exist.Specific user doesn’t have WMI access permission. Useful web linksLinks related to WMI ConfigurationDescriptionURLConnecting to WMI on a Remote Computer (Windows)(VS.85).aspxWMI Service Log Files (Windows)(VS.85).aspxConnecting thru Windows Firewall(VS.85).aspxConnecting to WMI Remotely starting with Windows Vista(VS.85).aspxSecuring a remote WMI connection (has details on DCOM configuration entries)(VS.85).aspxConnecting Between Different Operating Systems(VS.85).aspxUsing Distributed COM with Firewalls to configure RPC dynamic port allocation to work with firewalls related to WMI troubleshootingDescriptionURLWindows Management Instrumentation (WMI): Frequently Asked Questions Diagnosis Utility – Version 2.0 Administrative Tools (includes WMI CIM Studio) WMI Activity(VS.85).aspxTurn WMI error logging on or off(WS.10).aspxAsk the Performance Team: WMI Debug Logging scenarios we need to test outHost refers to machine from which we are initiating WMI connection. Target refers to the machine to which we are attempting WMI connection.The login account used to reach the target should be an account belonging to an administrator group on the target. Create a separate account (part of Administrator group) instead of the Administrator login itself.The host machine and the target machine have to be in the local WORKGROUP. Ideally, testing the following combinations would help us out.Host on local WORKGROUP, target on local WORKGROUPHost on local WORKGROUP, target joined to a DOMAINHost joined to a DOMAIN, target on local WORKGROUPHost joined to a DOMAIN, target joined to a DOMAINBut the HOST and TARGET on their local WORKGROUPS would be the most troublesome scenario and we can focus our test activities on this combination.Windows Firewall ENABLED on both ends would be the most important test case that needs to passIf we have a third party firewall software, we can put the machines behind the third party firewall and check to see how the behavior works out. #Test CaseHost OSTarget OSWindows Firewall ConfigurationHostTarget1Connecting from pre Vista hosts to pre Vista targetsOne of Windows 2000, Windows XP, Windows 2003One of Windows 2000, Windows XP, Windows 2003DISABLEDDISABLEDDISABLEDENABLEDENABLEDDISABLEDENABLEDENABLED2Connecting from pre Vista hosts to Vista & above targetsOne of Windows 2000, Windows XP, Windows 2003One of Vista, Windows 2008, Windows 7DISABLEDDISABLEDDISABLEDENABLEDENABLEDDISABLEDENABLEDENABLED3Connecting from Vista hosts to pre Vista targetsOne of Vista, Windows 2008, Windows 7One of Windows 2000, Windows XP, Windows 2003DISABLEDDISABLEDDISABLEDENABLEDENABLEDDISABLEDENABLEDENABLED4Connecting from Vista hosts to Vista targetsOne of Vista, Windows 2008, Windows 7One of Vista, Windows 2008, Windows 7DISABLEDDISABLEDDISABLEDENABLEDENABLEDDISABLEDENABLEDENABLED ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download