The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
You might get a security message if you open the home page (Default.aspx) in Internet Explorer on a Windows 2003 computer that has the Internet Explorer Enhanced Security Configuration component enabled. The WRA site could be identified as an Internet, or untrusted, zone, and does not appear.
Use one of the following solutions:
– In IE, choose Tools / Internet Options , and on the Security tab, click Local intranet.
– Click Sites , click Advanced , and add the WRA server URL to the intranet zone.
For more information, see Microsoft Knowledgebase Article 303650 .
The Device check-in interval setting on the Server Settings page in the Orchestrator Administrator console can affect how long a wake request takes if both of the following conditions are true:
Under these conditions, if a user sends a wake request to a client through WRA shortly after the last check-in by the client, the wake process can take almost as long as the check-in interval.
By contrast, if the computer is asleep, it receives the wake request when the server makes the request available.
To resolve this issue, set AutoPing to true, which is the default.
Note The wake-results page alerts the user that frequent timeouts can mean that the computer is awake. It suggests that the user try to log in normally.
This problem can occur if the user running the WRA service is not a member of the Windows group IIS_WPG on the IIS server. For information, see the “WRA Permissions Requirements” section and Microsoft Knowledgebase Article 918041 .
An application error occurred on the server. The custom error settings prevent the details of the application error from being seen remotely for security reasons. It could, however, be displayed by browsers running on the local server machine.
To resolve this issue, display the web page from the computer on which WRA is installed or temporarily enable remote display of error details.
Note Enabling remote display of error details might impact WRA performance and should only be used temporarily.
An user performs a search, and the results return more than one computer with the same name.
Open the Orchestrator Administrator console, and display the duplicate computers to see why there are two or more of them.
Most commonly, this issue occurs if you need to replace a computer or a network card but still use the original computer name. The Last Connected value can help you determine whether this is the case. Make sure that instances of the computer that are not in current use are unlicensed in Orchestrator so that they do not appear in WRA search results.
You can use the WRA test files if the issue is not covered in the “Connection Issues” section. These files can provide you and Cisco Technical Support with useful information for where to start troubleshooting.
The test files are in the Inetpub\wwwroot\WRA directory.
When you receive an error message or cannot run Wake Up for Remote Access, open a web browser, and enter the test file URL in the address bar. For example, http://YourServerName/WRA/test file name , where test file name is one of these:
The results tell you where the tests failed. For example, if Result shows Connected , but the Permissions Test shows Failed , you know that you have access to the power management server, but the current user does not have the required permissions on the power management server.