Troubleshooting
If you have problems with a SolarWinds product, the causes are usually related to an incorrect configuration or corrupted files. The suggestions listed in this section can often clear up these problems.
Additionally, you can visit our knowledge base repository for articles to help remedy specific issues. The address is:http://knowledgebase.solarwinds.com/kb/
You can also talk to other users as well as the SolarWinds staff by logging on to
thwack.com
Back Up Your Data
As a first step in any troubleshooting procedure, you should back up your Orion database. For more information, see “Creating Database Backups” on page 1. Verify Program Operation
SolarWinds runs many components at the same time to deliver a view of your network status. Confirm that the following components are running on your SolarWinds server:
Services:
l Message Queuing
l Net.Tcp Port Sharing Service l SNMP Trap Service
l SolarWinds Alerting Engine service
l SolarWinds Collector Data Processor, Management Agent, and Polling Con-troller services
l SolarWinds Information Service
l SolarWinds Job Engine and Job Engine v2 l SolarWinds Job Scheduler
l SolarWinds Network Performance Monitor Service. All SolarWinds products use this service. It is not exclusive to SolarWinds SAM.
l SolarWinds Product services l SolarWinds Information Service l SolarWinds Module Engine
l SQL Server
l Internet Information Service (IIS) Stop and Restart
Many problems disappear when programs are restarted. Stopping and restarting Internet Information Service (IIS) may eliminate web page problems. Problems with polling or data gathering may be eliminated by stopping and restarting the SolarWinds Network Performance Monitor Service using the available shutdown tool that you can locate as follows:
1. Click Start > All Programs > SolarWinds > Advanced Features > Orion Service Manager.
For a complete refresh of the system, reboot the computer. Run the Configuration Wizard
Running the Configuration Wizard, which refreshes files on the web server and performs checks on the structure of your database, may solve many problems. Note: Before you run the Configuration Wizard, you should close all open applications and stop the SolarWinds Network Performance Monitor Service in the Windows Services Control Panel. It will be restarted by the Wizard at the end of its process.
Using Full Variable Names
If you are having difficulty acquiring expected values from a selected variable, using the ${VariableName}format, it may be helpful to include the database table name within the variable name, as in ${Nodes.IP_Address}.
Slow Performance on Windows Server 2008
If SolarWinds is installed on Windows Server 2008 or Windows Vista and there are any devices on your network, between your SolarWinds server and your database server, that do not supportRFC 1323, “TCP Extensions for High
Performance,” the TCP window size auto-tuning feature of Windows Server 2008 and Windows Vista may prevent your SolarWinds server from successfully
connecting with your Orion database. This TCP auto-tuning feature is intended as a network-sensitive restriction, applied by the receiver—your SolarWinds
server—on the amount of data it is allowed or able to receive. If any devices along the network path between your SolarWinds server and your Orion database do not support the TCP window scaling detailed in RFC 1323, the allowed size of the TCP window in packets sent to your SolarWinds server may not match the
TCP window size reported by packets sent from your SolarWinds server. This mismatch may lead to failed connections between your SolarWinds server and your Orion database. The following procedure disables this TCP auto-tuning feature, resetting the TCP receive window to 64kB.
To Disable TCP Auto-tuning:
1. Click Start > All Programs > Accessories.
2. Right-click Command Prompt, and then click Run as administrator. 3. If you are prompted by User Account Control, click Continue to open
the elevated command prompt.
Note: In some cases, having User Account Control (UAC) enabled on Win-dows Server 2008 and WinWin-dows Vista (evaluation-only) can lead to install-ation errors. For more informinstall-ation about disabling UAC, see the article, “Disabling User Account Control (UAC)” in the SolarWinds Knowledge Base.
4. At the prompt, enter the following:netsh interface tcp set global auto-tuninglevel=disabled
5. Close the command prompt window, and then restart your SolarWinds server.
Why do my SAM WMI Monitors Show Status
Unknown?
To monitor SAM applications containing WMI component monitors, the following conditions must be true:
l WMI on the remote server is enabled and functioning properly.
l The remote server is accessible through a RPC connection in order to run the WMI queries.
If these conditions cannot be met, the WMI component monitors in SAM show an Unknown status. Examples of some issues that can prevent these conditions from being met include, but are not limited to:
l Trying to connect to a remote computer where you do not have local Admin-istrator rights.
l A firewall blocking the WMI traffic.
l An operating system that is not configured for WMI.
l Mistyping the credential password in the SAM component monitor.
To help diagnose and fix these issues and others, we can test the WMI services, To Disable TCP Auto-tuning:
to discover and correct the issues that can prevent your WMI component monitors from functioning correctly.
The topics in this guide are as follows:
l WMI Troubleshooting Flowchart for SolarWinds SAM. Provides a flowchart of the troubleshooting decisions described in this guide.
l Testing Local WMI Services. Ensures WMI is running correctly on the target computer.
l Testing Remote WMI Connections. Ensures the WMI connection to the tar-get computer is not being blocked, ignored, or rejected.
l Testing SolarWinds SAM Component Configuration. Ensures you are prop-erly configuring the WMI component credentials in SolarWinds SAM.
Working with Temporary Directories
The following sections provide procedures for moving Windows and SQL Server temporary directories to optimize SolarWinds server performance and resources.
Moving the SQL Server Temporary Directory
The SQL Server temporary directory, tempdb, where temporary database objects generated during table creation and sorting are stored, is typically created in the same location on your Orion database server as the master, model, and msdb databases. Moving the tempdb database to a physical drive separate from your Orion database can significantly improve overall system performance.
l For more information about moving the SQL Server 2008 temporary dir-ectory, tempdb, for see “Moving System Databases – Example A: Moving the tempdb Database.”
Redefining Windows System Temporary Directories
Following established Windows standards, the SolarWinds installer may use Windows User and System TEMP and TMP variable directories as temporary scratch spaces for file expansion and execution. If you do not have the required scratch space available in the default User or System TEMP and TMP directories, use the following procedure to redefine your default locations.
Note: Regardless of where you actually install SolarWinds, some common files may be installed where the operating system of your SolarWinds server are located.
To Redefine Default System Temporary Directories:
1. Log on to your SolarWinds server as a user with administrative rights. 2. Right-click My Computer, and then click Properties.
3. Click Advanced, and then click Environment Variables.
4. Select the variable name representing the directory you want to redefine, click Edit, and then provide a new path as the Variable value for the selec-ted temporary directory variable.
WMI Troubleshooting Flowchart for SolarWinds
SAM
Note: The following Microsoft article describes how to set permissions in a workgroup after an upgrade from Microsoft Windows 2000 Professional to Microsoft Windows XP Professional.http://support.microsoft.com/?kbid=290403
Testing Local WMI Services
Testing the local WMI services helps us isolate any faults on the target server we are trying to monitor. The testing program is a Microsoft program named
WBEMTest that comes already installed on Microsoft Windows operating systems.
Test WMI on the Target Server
Complete the following procedure to check whether WMI on the target server is functioning correctly:
1. Log on to the target server with an administrator account. 2. Click Start > Run, enter wbemtest.exe and then click OK.
3. Click Connect on the Windows Management Instrumentation Tester win-dow.
4. Enter root\cimv2 in the field at the top of the dialog box next to the Con-nect button.
5. Click Connect.
7. Select the Recursive radio button without entering a superclass name, and then click OK.
8. If the WMI class you are querying appears in this list, local WMI ser-vices are functioning correctly. Skip to the next topic and test remote WMI.
9. If the list does not appear or does not contain the desired WMI class, WMI is not functioning correctly. Continue reading this section for guidance on repairing WMI services on the target server.
10. Click Close, and then click Exit.
Reset the WMI Counters
At times, the WMI performance counters may not get transferred to WMI because services were delayed or started out of order
(http://support.microsoft.com/kb/820847). To manually reset the WMI counters:
1. Stop the Windows Management Instrumentation service. 2. Click Start, click Run, type cmd, and then click OK.
3. At the command prompt, type winmgmt /resyncperf, and then press Enter. 4. At the command prompt, type wmiadap.exe /f, and then press Enter.
5. Type exit, and then press Enter to close the command prompt. 6. Start the Windows Management Instrumentation service.
After resetting the WMI counters, retest WMI. If resetting the WMI counters did not solve your problem, see “WMI is Still Not Working. Now What?”
Testing Remote WMI Connectivity
Testing the remote WMI connectivity of the target server helps us isolate faults that could prevent the target server from receiving or responding to our remote WMI requests. The testing program is a Microsoft program named WBEMTest that comes already installed on Microsoft Windows operating systems.
Remotely Test WMI on the Target Server
Complete the following procedure to check whether the target server is responding appropriately to remote WMI requests that originate from the SolarWinds SAM server:
1. Log on to the SolarWinds SAM server with an administrator account. 2. Click Start > Run, enter wbemtest.exe and then click OK.
3. Click Connect on the Windows Management Instrumentation Tester win-dow.
4. Enter \\Target_Primary_IP_Address\root\cimv2 in the field at the top of the dialog box. Replace Target_Primary_IP_Address in the above example with the actual Hostname or Primary IP Address of the target server.
5. Enter the user name in the User field, the password in the Password field, and NTLMDOMAIN:NameOfDomain in the Authority field. Replace NameOfDomain with the domain of the user account specified in the User field.
6. Click Connect.
7. Click Enum Classes.
8. Select the Recursive radio button without entering a superclass name, and then click OK.
9. If the WMI class list appears, remote WMI is functioning correctly. Skip to the next topic and test your SAM credentials.
10. If the list does not appear, remote WMI is not functioning correctly. Continue reading this topic for guidance on restoring remote WMI con-nections on the target server, and retest remote WMI after completing each troubleshooting step.
Verify Administrator Credentials
Only a credential that has administrator rights on the target server has the
necessary permissions to access the target server’s WMI services. Make sure that the username and password you are using belongs to an administrator on the target server.
If the administrator credential is a domain member, be sure to specify both the user name and the domain in the standard Microsoft syntax. For example: DOMAIN\Administrator.
Enable Remote Procedure Call (RPC)
Remote WMI connections use RPC as a communications interface. If the RPC service is disabled on the target server, remote WMI connections cannot be established.
To enable the RPC service:
1. Log on to the target server with an administrator account.
2. Click Start, click Run, type services.msc, and then press Enter. 3. Scroll the list to Remote Procedure Call (RPC)
4. Right-click Remote Procedure Call (RPC), and then click Start on the shortcut menu.
Configure Distributed Component Object Model (DCOM) and User
Account Control (UAC)
If the target computer is running Windows Vista or Windows Server 2008, you may be required to make settings changes to allow remote WMI requests (http://msdn.microsoft.com/en-us/library/aa822854(VS.85).aspx).
Item Need
DCOM
l Default and Limits permissions edited to allow the fol-lowing actions:
l Local launch (default permission) l Remote launch (default permission) l Local activation (limits permission) l Remote activation (limits permission)
l For more information, see “Enabling DCOM”
WMI
Namespaces
l Modify the CIMV2 security to enable and remote enable the account used to access the server or workstation through WMI. You must ensure the security change applies to the current namespace and sub-namespaces. For more information, see “Enabling Account Privileges in WMI”
User Account Control
l Remote UAC access token filtering must be disabled when monitoring within a workgroup environment. For more information, see “Disabling Remote User Account Control for Workgroups”
Enabling DCOM
WMI uses DCOM to communicate with monitored target computers. Therefore, for Server & Application Monitor to use WMI, DCOM must be enabled and properly configured.
To enable DCOM permissions for your Server & Application Monitor cre-dentials:
1. Log on to the target server with an administrator account.
2. Navigate to Start > Control Panel > Administrative Tools > Component Services. You need to switch to the Classic View of the Control Panel to use this navigation path. You can also launch this console by
double-clicking comexp.msc in the /windows/system32 directory. 3. Expand Component Services > Computers.
4. Right-click My Computer, and then select Properties.
5. Select the COM Security tab, and then click Edit Limits in the Access Per-missions grouping.
6. Ensure the user account you want to use to collect WMI statistics has Local Access and Remote Access, and then click OK.
7. Click Edit Default, and then ensure the user account you want to use to collect WMI statistics has Local Access and Remote Access,
8. Click OK.
9. Click Edit Limits in the Launch and Activation Permissions grouping. 10. Ensure the user account you want to use to collect WMI statistics has
Local Launch, Remote Launch, Local Activation, and Remote Activ-ation, and then click OK.
11. Click Edit Default, and then ensure the user account you want to use to collect WMI statistics Local Launch, Remote Launch, Local Activation, and Remote Activation.
12. Click OK.
Enabling Account Privileges in WMI
The account you specify in the Credentials Library must possess security access to the namespace and sub-namespaces of the monitored target computer. To enable these privileges, complete the following procedure.
To enable namespace and sub-namespaces privileges:
1. 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 com-puter and ensure you grant the following permissions:
Enable Account Remote Enable
6. Click Advanced, and then select the user account used to access this com-puter.
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. Click Services in the left navigation pane of Computer Management. 11. Select Windows Management Instrumentation in the Services result
pane, and then click Restart.
Disabling Remote User Account Control for Workgroups
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\Mi-crosoft\Windows\CurrentVersion\Policies\System. 5. Locate or create a DWORD entry named
LocalAc-countTokenFilterPolicy and provide a DWORD value of 1. Note: To re-enable remote UAC, change this value to 0.
Add a Windows Firewall Exception for Remote WMI Connections
If the target computer has Windows Firewall enabled, it must have a Remote WMI exception to allow remote WMI traffic through ( http://msdn.microsoft.com/en-us/library/aa389286(VS.85).aspx).
To add this exception:
1. Click Start, click Run, type cmd and then press Enter.
2. At the command prompt, type netsh advfirewall firewall set rule group-p="Windows Remote Management" new enable=yes, and then press Enter.
3. At the command prompt, type exit, and then press Enter.
If adding the firewall exception did not solve your problem, see “WMI is Still Not Working. Now What?”
Do You Need an Additional Polling Engine?
Symptoms that may indicate you need an additional polling engine include, but are not limited to, the following:
l Polling completion rates are lower than expected which leads to gaps in data.
l Sporadic component monitor timeouts usually resulting in component mon-itors showing an "Unknown" status, reporting the error, "Connection
timeout. Job cancelled by scheduler." l Resource exhaustion on the SQL server.
For more information, see "Additional Polling Engine and Web Console" on page 1.
Verify SAM Component Configuration
Make sure that the credential you are using for remote WMI is the same credential that you are using in the SAM component.
After you click Set Component Credentials to set the component credentials, you must also click Submit at the bottom of the page.
Service reporting, "Invalid Class"
There are various possibilities for this to occur. Read the following section to help troubleshoot this issue. In APM v4 and higher, services can be polled via RPC or WMI. Ensure the correct service is running by navigating to Edit Application > RPC or WMI.
Repair the WMI Repository according to this KB article:
http://knowledgebase.solarwinds.com/kb/questions/633/Error+message+%22Inva
Note: Vista and Windows 2008 have a built-in method for repairing the WMI repository. Open an Administrator command prompt and run: winmgmt /salvagerepository
If you are using APM prior to version 4 and using WMI, try the following: There are three required WMI queries for service monitoring to work:
SELECT * FROM Win32_Service SELECT * FROM Win32_Process
SELECT * FROM Win32_PerfRawData_PerfProc_Process
You can test these by going to Start > Run > WBEMTEST on the SolarWinds server.
1. Click on Connect.
2. In the whitespace at the top, you should have \\ipaddress\root\CIMV2 3. For user and password, fill in the credentials used in APM.
4. For Authority, type in NTLMDOMAIN: and enter your domain. 5. Click Connect.
6. Click Query
7. Enter the above three queries, one at a time.
More often than not, the culprit is the last query. If your problem still exists, try the following:
1. Re-sync the counters by opening a command prompt and typing: winmgmt /resyncperf
2. Check to make sure performance counters are not disabled: http://th- wack.com/forums/68/application--server-management/21/application-per-formance-monitor/23124/win32perfrawdataperfprocpro/
Note: WMI is an operating system component. If the previous steps do no work, you may need to contact Microsoft for further information.
WMI is Still Not Working. Now What?
This guide depicts only the most common scenarios that can cause WMI services to fail. If you are unable to get WMI services to work at this point, it is time to consult Microsoft on this topic.
l “WMI Troubleshooting.” Microsoft Developer Network. http://msdn.-microsoft.com/en-us/library/aa394603.aspx
Troubleshooting Hardware Health
This following sections describe possible causes and solutions concerning hardware resources either not being reported or being reported incorrectly:
l Hardware Prerequisite Checklist l Hardware Troubleshooting Flowchart l Troubleshooting an SNMP Node l Troubleshooting a WMI Node l Troubleshooting a VMWare Node
Hardware Prerequisite Checklist
If the following conditions cannot be met, the Hardware Health resources will not be displayed. To monitor hardware in SAM, the following must be true:
l The monitored node must be HP Proliant, Dell PoweEdge, IBM X-Series, HP C7000, HP C3000, or Dell M1000e.
l The node must be monitored using one of the following protocols: l SNMP
l WMI
l ICMP nodes are allowed for VMWare when the Poll for VMware option is selected.
l The Hardware Monitoring Agent software, (provided by the vendor), is installed on the remote server. This applies for both SNMP and WMI. Required software can be found at "Monitoring Hardware Health".
l For VMware, the minimum requirements are as follows: ESX server version 3.5, 4.0, 4.1, ESXi version 5.0, vCenter version 4.0, 4.1, 5.0.
The following systems have been verified to work properly with SAM's hardware monitoring features.
Note: Other systems may work as well.
l Dell PowerEdge M610, R210, R610, R710, R900, 1950, 2850, 2950, 2970, 6850
l HP ProLiant DL320 G4, DL360 G3, DL360 G4, DL380 G4, DL380 G6, ML570 G3
l IBM IBM System x3550, System x3550 M2, System x3550 M3, System x3650, System x3650 M2, System x3650 M3, x3850, eServer 306m l HP C7000, HP C3000
l Dell M1000e.
Note: IBM's ServeRAID Manager software must be installed on IBM X-Series Troubleshooting Hardware Health
SAM. HP’s WBEM providers are required for HP servers polled via WMI. Installation instructions can be at "Monitoring Hardware Health" on page 1.
Hardware Troubleshooting Flowchart
Note: Dell does not make array and hard disk health information visible from WMI managed nodes. To monitor storage health on Dell servers, use SNMP.
Troubleshooting an SNMP Node
The most common issue customers face is that hardware information is not available via SNMP because the Hardware Monitoring Agent software was installed before SNMP was installed. This means MIBs were never installed and/or configured correctly. The easiest solution is to uninstall and then re-install the Hardware Monitoring Agent software after installing SNMP on the server. If this is not the case, follow the troubleshooting steps as outlined below:
Verify the node was successfully added using SNMP:
1. Verify the polling method on the Node Details page as shown below:
2. Verify the Hardware Monitoring Agent software is installed on the remote server and running. For verification instructions, see "Accessing Hardware Monitoring Agent Software" on page 1.
3. Determine if SNMP responds for the proper OID. Below are the correct OIDS for each vendor:
For HP:1.3.6.1.4.1.232.2.2.2.1.0
For Dell:1.3.6.1.4.1.674.10892.1.300.10.1.8.1 For IBM:1.3.6.1.4.1.2.6.159.1.1.60.3.1
l To determine if the remote server responds to the correct OID, you can use the MIB browser from SolarWinds Engineer’s Toolset, which can be down-loaded fromhttp://www.solarwinds.com/downloads/. Additionally, you can use other applications capable of making SNMP requests.
If you do not have a tool for checking OIDs on the remote server, you can create an SNMP walk by using the SNMPWalk.exe installed with SAM, normally located at C:\Program Files (x86)\SolarWinds\Orion\SnmpWalk.exe. SNMPWalk.exe will be used in this demonstration.
Using SNMPWalk.exe:
1. Start SNMPWalk.exe and type in the IP address of the remote server and the community string for SNMP.
2. Click Scan.
3. After completing the scan, save the SNMP walk in a text file. 4. Open the text file and manually search for the OIDs.
If the Remote Server does not respond on this OID, the Hardware Monitoring Agent software may not be properly configured. Check to see if the Hardware Monitoring Agent software has imported the correct MIBs as outlined in the following table.
For information on verifying Hardware Monitoring Agent software, see "Accessing Hardware Monitoring Agent Software" on page 1.
HP Dell IBM
CPQSTDEQ-MIB
MIB-Dell-10892 IBM-SYSTEM-HEALTH-MIB
CPQSINFO- StorageManagement- IBM-SYSTEM-ASSETID-MIB
MIB MIB CPQIDA-MIB IBM-SYSTEM-LMSENSOR-MIB CPQHLTH-MIB IBM-SYSTEM-MEMORY-MIB CPQSTSYS-MIB IBM-SYSTEM-POWER-MIB CPQIDE-MIB IBM-SYSTEM-PROCESSOR-MIB IBM-SYSTEM-RAID-MIB ADAPTEC-UNIVERSAL-STORAGE-MIB
Troubleshooting a WMI Node
The following conditions must be met before you can proceed troubleshooting WMI nodes:
l The node has successfully been added via WMI. l WMI is working properly on the remote server.
l The Hardware Monitoring Agent software is installed on the remote server and running.
Using Wbemtest.exe to troubleshoot WMI:
1. Open wbemtest.exe, usually located at C:\Win-dows\System32\wbem\wbemtest.exe.
2. Connect from the problematic node (either the SAM server or the additional poller server) to the remote server using wbemtest.exe.
3. Click Connect.
4. In the Namespace field enter:
For IBM and HP enter:\\RemoteServerIpAddress\root
5. Enter administrator credentials.
6. Click Connect.
7. Once connected, click Query… from the main screen. The Query dialog appears.
8. Enter: select * from __Namespace
9. Replace Namespace with the following:
l For HP nodes, replace Namespace with HPQ l For Dell nodes, replace Namespace with Dell l For IBM nodes, replace Namespace with IBMSD
10. If the proper Namespace is found, connect to this Namespace. l \\RemoteServerIpAddress\root\IBMSDfor IBM.
l \\RemoteServerIpAddress\root\HPQfor HP.
l \\RemoteServerIpAddress\root\cimv2\Dellfor Dell.
11. Run a Query for specific information:
Select Manufacturer, Model, SerialNumber from CIM_Chassis
12. If the test was not successful, re-install the platform or Hardware Monitoring Agent software on the remote server with the latest release.
Troubleshooting a VMWare Node
VMWare nodes can be polled for Hardware information either through the vCenter or directly by using the CIM protocol. Polling through the vCenter uses
VMWare's native API interface. Polling the ESX server directly uses the CIM protocol to get Hardware information.
To determine if a node is polled through the vCenter or directly:
1. From the web console, navigate to Settings > Virtualization Settings 2. Listed will be table of all the currently polled VMWare nodes. This table
contains the Polling Through column.
Note: This column may be hidden. If the column is hidden, unhide it by clicking the drop down menu of an adjacent column and check the Polling Through option:
3. Use the illustration below to determine how your VMWare is being polled. To determine if a node is polled through the vCenter or directly:
Troubleshooting AppInsight for Exchange
The following sections will help you identify and correct AppInsight for Exchange errors concerning configuration and performance counters:
l Troubleshooting Error Codes in AppInsight for Exchange l Troubleshooting Exchange Performance Counters l Troubleshooting Permissions
l Changing between 32-bit and 64-bit polling methods:
Important:The following log file contains all the information and errors related to the WinRM configuration process:
C:\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log
Troubleshooting Permissions
The following information will help you troubleshoot issues with the following: l Non-Domain Accounts
l Adding Local Administrative privileges to Active Directory Account l Exchange Access
l Mailbox Exchange Access
Note: Mailboxes with an empty primary SMTP address can be polled; however, their Sent and Received statistics will not be not available.
Non-Domain Account
Local accounts (Non-Domain) cannot access Exchange Management interfaces and therefore are not supported by AppInsight for Exchange. Please select an Active Directory account or create a new one to use with AppInsight for
Exchange.
Add Local Administrative privileges to Active Directory Account
1. On the server where you want to grant local administrative privileges, open a Computer Management console.
2. Navigate to System Tools > Local Users and Groups > Groups and then double click the Administrators group.
3. Click Add and type in the Active Directory username of the account you want to grant administrative privileges to, and then press Enter. (Ensure the location is set to either the domain where the account is located or Entire Directory.)
4. Click Apply and then click OK.
5. Alternatively, you can add an Active Directory group to the Local Admin-istrators group and then add the AD user accounts to that group.
6. To verify the account and local group membership has been configured properly, run the following in a PowerShell session:
$Recurse = $true
$GroupName = 'Administrators'
Add-Type -AssemblyName System.DirectoryServices.AccountManagement $ct = [Sys-tem.DirectoryServices.AccountManagement.ContextType]::Machine $group = [Sys- tem.Dir-ectoryServices.AccountManagement.GroupPrincipal]::FindByIdentity ($ct,$GroupName)
$LocalAdmin = $group.GetMembers($Recurse) | select @{N='Domain'; E= {$_.Context.Name}}, samaccountName, @{N='ObjectType'; E={$_.Struc-turalObjectClass}} -Unique
$LocalAdmin = $LocalAdmin | Where-Object {$_.ObjectType -eq "user"}
Exchange Access
Granting Least Privilege access to the Exchange Organization can be accomplished using Active Directory Users and Computers (ADUC)
1. From the Start Menu open ADUC and navigate to the Microsoft Exchange Security Groups OU.
2. Double click on the View-Only Organization Management group. 3. After the window opens, click the Members tab and then click Add. 4. Type the username of the account you want to grant access to the
Exchange organization, and then click OK. 5. Click Apply and then click OK .
6. Close the ADUC window.
Access can also be granted using the Exchange Management Shell with the following command:
Note: Replace the word "user" with the correct user name of the service account.
Add-RoleGroupMember -Identity "View-Only Organization Management" -Member "USER"
To verify the management role is properly assigned, use the following commands:
Get-RoleGroupMember -Identity "View-Only Organization Management" | Where-Object {$_.SamAccountName -eq "USER"}
Get-RoleGroupMember -Identity "Organization Management" | Where-Object {$_.SamAccountName -eq "USER"}
or
Get-ManagementRoleAssignment -RoleAssignee “USER” | Where-Object {$_.RoleAssigneeName -eq "View-Only Organization Management" -or $_.RoleAssigneeName -eq "Organization Management"}
Mailbox Search Access
Mailbox Search access is required to determine attachment counts and sizes. It
can be granted using the Exchange Management Shell (EMS). 1. From the Start Menu, open the EMS.
2. Type:New-ManagementRoleAssignment -Role "Mailbox Search" -User "USER"and press Enter.
To verify the management role has been properly assigned, use the following command:
Get-ManagementRoleAssignment -RoleAssignee “USER” -Role "Mailbox Search" | Where-Object
{$_.RoleAssign-mentDelegationType -eq "Regular"}
Note: Exchange Management Roles can be assigned to role assignees using either regular or delegating role assignments.
l Regular role assignments enable the role assignee to access the permissions provided by the management role entries on this role.
l Delegating role assignments give the role assignee the ability to assign this role to Role Groups, Users, or Universal Security Groups.
For more information, see:
l http://technet.microsoft.com/en-us/library/dd876958(v=exchg.150).aspx l
http://www.powershellmagazine.com/2013/05/23/pstip-retrieve-group-mem-bership-of-an-active-directory-group-recursively/
Troubleshooting Exchange Performance Counters
Occasionally, you may encounter an Exchange server which is missing some of the expected performance counters. If this happens, you need to verify whether the counters are simply disabled or if they are completely missing. The simplest way to do this is through the registry.
1. Navigate to the service with the missing performance counters. Note: Individual services are listed under HKLM\SYSTEM\Cur-rentControlSet\Services.
2. Expand the service and click on the Performance key. The important val-ues we want to ensure exist are listed below and displayed in Figure 1.
[HKEY_LOCAL_MACHINE\SYSTEM\Cur-rentControlSet\Services\<ServiceName>\Performance] Example: [HKEY_LOCAL_MACHINE\SYSTEM\Cur-rentControlSet\Services\ESE\Performance] "Close"="ClosePerformanceData" "Collect"="CollectPerformanceData"
"Library"="<Path to performance counter DLL file>"
Example:"Library"="C:\\Program Files\\Microsoft\\Exchange Server\\V15\bin\\perf\\%PROCESSOR_ARCHITECTURE%\\eseperf.dll"
"Open"="OpenPerformanceData"
"PerfIniFile"="<Name of performance counter INI file>"
Example:"PerfIniFile"="eseperf.ini"
The "Library" file path is typically"C:\Program Files\Microsoft\Exchange
Server\%ExchangeVersion%\Bin\perf\%Processor_ Architecture%\%DLLFileName%"
Figure 1.
3. Verify the counters have not been disabled by expand the service and then clicking on the "Performance" key.
4. Check for the value Disable Performance Counters (See Figure 2.) If this value exists, ensure the data value is 0. Any other value will disable the counters.
5. Once the value is confirmed to be set to 0, close all PerfMon windows and then reopen them.
Note: The performance counters should be visible at this time. If the per-formance counters are not visible, proceed to the next step.
6. If the values First Counter, First Help, Last Counter, and Last Help are lis-ted (See Figure 3), it is highly recommended to unload the performance counters prior to reloading them.
Figure 3.
To Unload Performance Counters: (See Figure 4)
1. Close all PerfMon windows and stop any services which may be using these counters.
2. Open the Exchange Management Shell (EMS) in the Run as Administrator context.
3. Type:Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
and then press Enter.
4. Type:Remove-PerfCounters -DefinitionFileName "<Path to counter
a. The default location for Exchange counter definition files is: C:\Pro-gram Files\Microsoft\Exchange
Server-\%ExchangeVersion%\Setup\perf\%XMLFileName%
To Reload Performance Counters: (See Figure 4)
1. Close all PerfMon windows and stop any services which may be using these counters.
2. Open the Exchange Management Shell (EMS) in the Run As Administrator context.
3. Type: Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Setup
and then press Enter.
4. Type: New-PerfCounters -DefinitionFileName "<Path to counter defin-ition XML file> and then press Enter.
a. The default location for Exchange counter definition files is: C:\Pro-gram Files\Microsoft\Exchange
Server-\%ExchangeVersion%\Setup\perf\%XMLFileName%
5. Check the application log to verify the counters were properly loaded and no PerfLib errors exist. Reopen PerfMon to ensure the counters are avail-able.
Figure 4.
Troubleshooting Error Codes in AppInsight for Exchange
Following are the possible error messages associated with AppInsight for Exchange. Included are possible causes and solutions.
Important:The following log file contains all the information and errors related to the WinRM configuration process:
C:\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log
Configuration Errors
Error Message, Information, and Remediation
Error message: Remote configuration was unsuccessful due to the following:
"The deployment service executable was not found on the Orion server." For details, see the log on the Orion server: ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: Internal error. TheRemote Installation Service.exefile was not
found. (Default file location:C:\Program Files (x86)\SolarWinds\Orion\APM).
This can be caused by an incorrect SAM installation orRemote Installation Service.exewas deleted or modified.
Remediation: Add theRemote Installation Service.exe file to the following
folder:C:\Program Files (x86)\SolarWinds\Orion\APM.
Error message: Remote configuration was
unsuccessful due to the following: "Failed to start Windows Remote Management" For details, see the log on the Orion server: ([ALLUSERSPROFILE] \ProgramData\Solarwinds\Logs\APM\RemoteExecu
tableStarter.log).
Remediation:
1. On the target Exchange server, navigate to the Windows Services console and find the
Windows Remote Management (WS-Man-agement) service.
2. Set Startup type to Automatic.
3. Start the Windows Remote Management
(WS-Management) service.
Error: Unable to access remote administrator share.
Cause: The remote administrator share cannot be accessed.
Resolution: Try enabling this feature manually by taking the following steps:
1. Ensure that both computers belong to the same Workgroup.
2. Specify which user(s) can access the Admin-istrator Shares (Disk Volumes).
3. Enable File and print sharing through the Windows firewall.
4. Check to see if you can access the Admin-istrator share from another computer. 5. When complete, rerun the AppInsight for
Exchange Automatic Configuration Wizard.
Error message: Remote configuration was unsuccessful due to the following:
"The configurator executable was not found on the Orion server." For details, see the log on the Orion server: ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: Internal error.SolarWinds.APM.RemoteWinRmConfiguratorFull.exe
file was not found (Default file location:C:\Program Files (x86)
\SolarWinds\Orion\APM). This can be caused by an incorrect SAM installation or
SolarWinds.APM.RemoteWinRmConfiguratorFull.exe was deleted or modified..
Remediation: AddSolarWinds.APM.RemoteWinRmConfiguratorFull.exeto the
following folder:C:\Program Files (x86)\SolarWinds\Orion\APM.
Error message: Remote configuration was unsuccessful due to the following:
"Access denied." For details, see the log on the Orion server:
([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: The provided user account does not have access to the Administrator share on the remote Exchange server.
Remediation: Connect to the Administrator share with
Error message: Remote configuration was unsuccessful due to the following:
"The configurator executable has an invalid signature." For details, see the log on the Orion server: ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: The configuration executable cannot be started on the remote Exchange server due to any of the following:
l The high level of User Account Control settings
l The provided user account does not have privileges high enough to run *.exe files
l SolarWinds.APM.RemoteWinRmConfiguratorFull.exeis not signed with a
Solarwinds certificate. Remediation:
l Reduce User Account Control settings on the remote Exchange server; l Ensure the user's account has privileges to run*.exe files
Error message: Remote configuration was unsuccessful due to the following:
"The network path was not found." For details, see the log on the Orion server:
([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: This is a Windows error indicating that a networking component is malfunctioning.
Remediation:
l Ensure you have access to the Shared Storage drive.
1. In Windows Explorer, navigate to My Network Places > Entire Net-work > Microsoft Windows NetNet-work > (Net-workgroup name) > (Shared Storage drive name).
l Firewalls can block traffic to the network which could generate this mes-sage. Try temporarily disabling any software or hardware firewalls to isol-ate the problem.
anti-spyware programs and restart the computer to isolate the problem.
Error message: Remote configuration was unsuccessful due to the following:
"Executable configuration file was not found on the Orion server." For details, see the log on the Orion server: ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).
Description: Internal error.
SolarWinds.APM.RemoteWinRmConfiguratorFull.exe.configwas not found
(Default file location:C:\Program Files (x86)\SolarWinds\Orion\APM.) This
can be caused by an incorrect SAM installation or
SolarWinds.APM.RemoteWinRmConfiguratorFull.exe.configwas deleted or
modified.
Remediation: AddSolarWinds.APM.RemoteWinRmConfiguratorFull.exe.config
to the following location:C:\Program Files (x86)\SolarWinds\Orion\APM.
For information about Microsoft error codes, see: http://msdn.microsoft.com/en-us/library/cc231199.aspx
Error message: Remote configuration was unsuccessful due to the following:
"PowerShell 2.0 was not detected on the Exchange server." Learn how to
correct this. For details, see the log on the remote computer. ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log).
Description: PowerShell 2.0 is not installed on the remote Exchange server. Remediation: PowerShell 2.0 should be installed on Exchange server.
Installing PowerShell 2.0 on Server 2008:
For Server 2008, download the installation file for PowerShell 2.0 at
http://support.microsoft.com/kb/968929/en-us and install it on the server.
Note: PowerShell 2.0 is automatically installed on Server 2008 R2 and therefore no additional installation is required.
Installing PowerShell 2.0 on Server 2012: 1. Open Server Manager.
2. Click on the Manage menu, and the select Add Roles and Features.
3. After the wizard opens, click Next until you get to the
Install-ation Type page.
4. Select Role-based or feature-based installation. 5. Click Next until you reach the Features page.
6. Scroll down to Windows PowerShell. It will likely show itself as partially installed (square inside box).
7. Check the box next to Windows PowerShell 2.0 Engine. 8. Click Next and then Install.
9. When the installation finishes, click Close.
Error message: Remote configuration was unsuccessful due to the following:
privileges." Learn how to correct this. For details, see the log on the remote computer. ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log).
Description: The provided user account does not have Local Administrative privileges.
Remediation:
Add Local Administrative privileges to Active Directory Account:
1. On the server where you wish to grant local administrative privileges, open a Computer Management console.
Note: On Windows 2012, add this privilege using the Active Directory con-sole.
2. Navigate to System Tools > Local Users and Groups > Groups and double click the Administrators group.
3. Click Add and type in the Active Directory username of the account you want to grant administrative privileges, and then press Enter. (Ensure the location is set to either the domain where the account is located or Entire Directory.)
4. Click Apply and then click OK.
Note: Alternatively, you can add an Active Directory group to the local administrators group and add the Active Directory user accounts to that group.
Error message: Remote configuration was unsuccessful due to the following:
"This account must be an Active Directory account with organization wide Exchange access (View-Only-Organization Management and Mailbox Search Management Role)." Learn how to correct this. For details, see the log on the remote computer. ([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RunWinRMConfigurator.log).
Description: The provided user account does not have View-Only-Organization Management or Mailbox Search Management privileges.
Remediation:
Grant View-Only-Organization Management privileges:
Granting Least Privilege access to the Exchange Organization can be accomplished using Active Directory Users and Computers (ADUC). To accomplish this, take the following steps:
1. From the Start Menu, open ADUC and navigate to the Microsoft Exchange Security Groups OU.
2. Double click on the View-Only Organization Management group. 3. After the window opens, click the Members tab and then click Add. 4. Type the username of the account you want to grant access to the
Exchange organization, and then click OK. 5. Click Apply, and then click OK.
6. Close the ADUC window. Grant Mailbox Search Access:
Mailbox Search access is required to determine attachment counts and sizes. This can be granted using the Exchange Management Shell (EMS).
1. From the Start Menu, open the EMS.
2. Type: New-ManagementRoleAssignment -Role "Mailbox Search" -User <Username of account being granted access> and then press Enter.
3. To verify the management role has been properly assigned, enter the fol-lowing command:
Error message:Remote configuration was unsuccessful due to the following:
"An error occurred during Exchange Server Confiduration. Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed."
Cause: This is a Windows Limitation when trying to map multiple drives to the same computer using different user accounts.
Resolution:
1. Open the Computer Manager on the Exchange server 2. Expand Shared Folders and select Sessions.
3. Right-click on the users in the list and click Close Session.
4. Once the session list is empty, retry the Configure Server button in
AppInsight for Exchange.
For more information, seeSWKB5583.
Error message: Remote configuration was
unsuccessful due to the following: "WinRM test was successful. PowerShell Exchange web site testing failed with the following error: Connecting to remote server..."
Description: There are no default HTTPS bindings for all unassigned ports, (i.e. “HTTPS 443 *”.)
Remediation: Establish the missing default HTTPS binding with an Exchange certificate.
Troubleshooting AppInsight for IIS
The following sections will help you identify and correct AppInsight for IIS errors concerning configuration and performance counters. For example, you may see an error similar to the following:
l Changing between 32-bit and 64-bit polling methods: l Credentials Test Failed
l Polling fails due to a missing certificate. l IIS Polling Failed
l Node Unreachable. l IIS Version Failed l WinRM Testing Failed l Error Code 1367 l Error Code 1726 l Error Code 16004 l Error Code 16005 l Error Code 16006 l Error Code 16007 l Error Code 16008 l Error Code 16009 l Error Code 16013 l Error Code 16022 l Error Code 16023 l Error Code 16024 l Error Code 16029 l Error Code 16049 l Error code 16090 l Other Errors
l An HTTPS listener currently exists on port 5986: l Event IDs
Access is denied when configuring AppInsight for IIS
Issue: You may encounter access denied errors when you choose not to use the built-in administrator account for IIS polling. This can occur if you create a new user and then add this user to the Administrator's group.
Cause: If the group policy or the local policy has Administrator Approval Mode set to Enable, the polling will fail with an error. This is usually because the
administrator account does not have enough permissions. Resolution:
1. In your local security policy, navigate to Local Policies > Security Options > User Account Control: Run all administrators in Admin Approval Mode.
Note: This should be set to Disabled to let administrators poll properly. 2. Navigate to Local Policies > Security Options > User Account Control:
Admin Approval Mode for the Built-in Administrator Account.
Note: This should be Disabled for the built-in administrator to poll properly. 3. When complete, rerun the AppInsight for IIS Automatic Configuration
Wiz-ard.
Changing between 32-bit and 64-bit polling methods:
Using AppInsight applications with 32-bit polling on 64-bit computers via an agent may prevent certain performance counters from collecting information and should be changed to 64-bit polling.
To make this change at the application level, take the following steps: 1. From the web console, navigate to Home > Applications > Select an
AppInsight Application.
2. Click Edit Application Monitor.
3. Expand Advanced, and then click Override Template.
4. In the Platform to run polling job field, change the value tox64.
5. When done, click Submit.
To make this change at the template level, take the following steps: 1. From the web console, navigate to Settings > SAM Settings > Manage
Templates.
2. Select an AppInsight application and click Edit.
3. Expand Advanced, and in the Platform to run polling job field, change the value tox64.
continue to poll using 32-bit, regardless of this setting.
4. When done, click Submit. Credentials Test Failed
Error: The credentials given are not valid. Please provide the correct credentials
for an account with WMI permissions.
Resolution: Enter valid credentials.
Polling fails due to a missing certificate.
Issue: You receive an error similar to the following: The SSL connection cannot
be established. Verify that the service on the remote host is properly configured to listen for HTTPS requests...
Cause: A PowerShell listener was created but its certificate is missing.
Resolution: Manually remove the existing PowerShell listener and re-run the IIS configuration wizard. This process will create a new listener along with the appropriate certificate needed.
IIS Polling Failed
Error: Application polling failed because IIS information is currently unavailable. Polling fails due to a missing certificate.
Cause: This is a general error message returned by Windows when a networking component is malfunctioning.
Resolution: For details, see the log on the Orion server located at:
([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log). Following
are some of the more common reasons why this error message might be returned by Windows:
E.G. Restart the remote registry service, check that TCP port 445 is open between the Orion server and the remotely monitored IIS server.
When complete, rerun the AppInsight for IIS Automatic Configuration Wizard. Node Unreachable.
Error: Credentials test failed. Node is unreachable.
Resolution: Ensure the node is currently being managed. For more information, see Unmanage Scheduling Utility. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
IIS Version Failed
Error: The current version of IIS is 6.0. Version 7.0 or higher is required.
Resolution: Install IIS version 7.0 or higher. When complete, rerun the AppInsight
for IIS Automatic Configuration Wizard.
WinRM Testing Failed
Error: WinRM testing failed with the following error: Connecting to remote server
failed with the following error message: Access is denied.
Resolution: Set the appropriate permissions for PowerShell on the target server. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard. Setting the appropriate permissions for PowerShell on the target server:
1. On the remote computer, open the PowerShell console.
2. Execute the following PowerShell command:Set-PSSessionConfiguration Microsoft.PowerShell -ShowSecurityDescriptorUI -force (The
3. Uncheck the Deny check box to enable the Full Control option under the
Permissions for Everyone group.
4. Ensure that the group to which the polling user belongs has access to Microsoft PowerShell.
5. Click OK. Error Code 1367
Error: Incorrect user name and/or password.
Resolution: Enter a valid user name and password combination. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
For more information, see Inherit Credentials from Node. Error Code 1726
Error: An error occurred during Server configuration.
Cause: This can be due to a temporarily slow network or a heavily taxed computer at the moment of configuration causing the remote installer not to receive the necessary exit codes. Configuration is most likely successful at this point and the displayed error message is simply a response to the exit codes not being returned.
Resolution: Running the configuration wizard again or clicking, I've already manually configured this server under Advanced should result in a successful configuration.
Error Code 16004
Error: The deployment service executable was not found on the Orion server. Cause: TheRemote Installation Service.exefile was not found. This could be
caused by an incorrect SAM installation or theRemote Installation Service.exe
was deleted or modified.
Resolution: Add theRemote Installation Service.exefile to the following
directory:C:\Program Files (x86)\SolarWinds\Orion\APM. For details, see the
log on the Orion server located at:([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log). When
complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16005
Error: The configuration executable was not found on the Orion server. Cause: TheSolarWinds.APM.RemoteIISConfigurator.exefile was not found.
This can be caused by an incorrect SAM installation or the
SolarWinds.APM.RemoteIISConfigurator.exe file was deleted or modified.
Resolution: Add theSolarWinds.APM.RemoteIISConfigurator.exefile to the
following directory:C:\Program Files (x86)\SolarWinds\Orion\APM. For details,
see the log on the Orion server located at:([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log).When
Error Code 16006 Error: Access denied.
Cause: The provided user account does not have access to the Administrator share on the remote IIS server.
Resolution: Ensure the provided user account has access to the Administrator share by trying to connect to the Administrator share with the following:
\\IISComputerName\<drive letter>$\from the Orion server. When complete,
rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16007
Cause: The configuration executable cannot be started on the remote IIS server due to one or more of the following:
l The high level of User Account Control settings;
l The provided user account does not have privileges to run executable files; l TheSolarWinds.APM.RemoteIISConfigurator.exefile is not signed with a
Solarwinds certificate.
Resolution: Try to lower the User Account Control settings on remote IIS server. Also check that the user account has privileges to run executable files. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16008
Cause: This is a general error message returned by Windows when a networking component is malfunctioning. This may be caused by not having the appropriate root or intermediate certificate on the remote IIS server.
Resolution: For details, see the log on the Orion server located at:
([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log). Following
are some of the more common reasons why this error message might be returned by Windows:
l Ensure you have access to the shared storage drive. To do this:
1. Open Windows Explorer and navigate to My Network Places > Entire Network > Microsoft Windows Network > (Workgroup name) > (Shared Storage drive name). When complete, rerun the AppInsight
for IIS Automatic Configuration Wizard.
l Firewalls can block traffic to the network which could generate this mes-sage. Try temporarily disabling any software or hardware firewalls to isolate the problem. When complete, rerun the AppInsight for IIS Automatic Con-figuration Wizard.
l Like firewalls, some anti-spyware tools have the same effect. Try tem-porarily disabling any anti-spyware programs and restart the computer to isolate the problem. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16009
Error: The configuration file for the configuration executable was not found on the
Orion server.
Cause: This is an internal error. This can be caused by either an incorrect SAM installation, or theSolarWinds.APM.RemoteIISConfigurator.exe.configfile was
deleted or modified.
Resolution: Add theSolarWinds.APM.RemoteIISConfigurator.exe.configfile to
the following directory:C:\Program Files (x86)\SolarWinds\Orion\APM.For
\ProgramData\Solarwinds\Logs\APM\RemoteExecutableStarter.log). When
complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16013
Error: Unable to access remote administrator share.
Cause: The remote administrator share cannot be accessed.
Resolution: Try enabling this feature manually by taking the following steps: 1. Ensure that both computers belong to the same Workgroup.
2. Specify which user(s) can access the Administrator Shares (Disk Volumes). 3. Enable File and print sharing through the Windows firewall.
4. Check to see if you can access the Administrator share from another com-Error Code 16013
5. When complete, rerun the AppInsight for IIS Automatic Configuration Wiz-ard.
Error Code 16022
Error: An HTTPS listener currently exists on port 5986.
Cause: This error means that an HTTPS listener already exists on port 5986 and cannot be reused because it is not configured to listen for the target IIS server IP address.
Resolution: For details, see the log on the target computer located at:
([ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteIISConfigurator.log & RemoteIISConfiguratorPowerShell.log).For configuring WinRM using a
Error Code 16023
Error: Unable to create a self-signed certificate.
Cause: An unexpected error occurred during the certificate creation process. Resolution: Check the configuration script log file located on target the IIS server, located at[ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteIISConfigurator.log. When
complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error Code 16024
Error: Unable to create wsMan listener.
Cause: This error means that an unexpected error occurred during wsMan listener creation.
Resolution: Check the configuration script log file located on the target IIS server at,[ALLUSERSPROFILE]
\ProgramData\Solarwinds\Logs\APM\RemoteIISConfigurator.log.When
Error Code 16029
Error: Failed to start Windows Remote Management.
Cause: This error means that the Windows Remote Management (WS-Management) service cannot be started remotely.
Resolution: The Windows Remote Management service should be running on the target IIS server. To do this, refer to the following steps:
Running Windows Remote Management (WS-Management) service on Server 2008\2012:
1. Open an RDP session to the remote server 2. Open Server Manager.
3. Click on the Local Server menu and find the Services window.
4. Right-click the Windows Remote Management (WS-Management) ser-vice, and then click Start
5. When complete, rerun the AppInsight for IIS Automatic Configuration Wiz-ard.
For more information, see Creating a WinRM Listener: Error Code 16049
Error: An unknown error occurred during IIS server configuration.
Resolution: For more information, see Other Errors. Once the problem is isolated, rerun the AppInsight for IIS Automatic Configuration Wizard.
Error code 16090
Error: PowerShell 2.0 or higher is required.
Cause: PowerShell 2.0 or higher is not installed on the target server. Resolution: Ensure that PowerShell 2.0 or higher is installed on the target server. When complete, rerun the AppInsight for IIS Automatic Configuration Wizard.
Installing PowerShell 2.0 on Windows Server 2008:
For Windows Server 2008, download the installation file for PowerShell 2.0 at
http://support.microsoft.com/kb/968929/en-usand install it on the target server. Note: PowerShell 2.0 is automatically installed on Windows Server 2008 R2 and therefore no additional installation is required.
Installing PowerShell 2.0 on Server 2012: 1. Open Server Manager.
2. Click on the Manage menu, and then select Add Roles and Features. 3. After the wizard opens, click Next until you get to the Installation Type page. 4. Select Role-based or feature-based installation.
5. Click Next until you reach the Features page.
7. Check the box next to Windows PowerShell 2.0 Engine. 8. Click Next and then Install.
9. When the installation finishes, click Close. Other Errors
Issue: PowerShell 2.0 is not Installed Resolution: Install PowerShell.
Installing PowerShell 2.0 on Server 2008:
For Server 2008, download the installation file for PowerShell 2.0 at
http://support.microsoft.com/kb/968929/en-us and install it on the server.
Note: PowerShell 2.0 is automatically installed on Server 2008 R2 and therefore no additional installation is required.
Installing PowerShell 2.0 on Server 2012: 1. Open Server Manager.
2. Click on the Manage menu, and the select Add Roles and Features.
3. After the wizard opens, click Next until you get to the Installation
Type page.
4. Select Role-based or feature-based installation. 5. Click Next until you reach the Features page.
6. Scroll down to Windows PowerShell. It will likely show itself as partially installed (square inside box).
7. Check the box next to Windows PowerShell 2.0 Engine. 8. Click Next and then Install.
9. When the installation finishes, click Close.
Setting the appropriate permissions for PowerShell on the target server:
1. On the remote computer, open the PowerShell console. 2. Execute the following PowerShell command:
Set-PSSes-sionConfiguration Microsoft.PowerShell
-ShowSe-curityDescriptorUI -force (The permissions dialog should
appear.)
3. Uncheck the Deny check box to enable the Full Control option under the Permissions for Everyone group.
