Click on the picture above to return to the main article "How to troubleshoot the 32-bit Console"
Identification is perhaps the most important but can be the most difficult pieces of troubleshooting a slow 32-bit Console. In many cases you can blindly check and optimize everything in sight but if possible it's better to identify the specific problem. Here is a list of questions to ask:
- Does the slowness happen for every user?
- Are the users affected at the same location or distance from the core and database?
- Is a WAN connection involved? If so does it work normal when located near the core and database?
- Did the problem start after making a change to the core or database server? After installing an application?
The use of 3rd party tools and tools included with Windows will help greatly in determining where a console is slow. Here is a quick list of tools that can help:
- Task Manager - This tool when configured properly can identify a lot of key issues. The tool has a little used configuration option to add-in other items not normally displayed.
- Black Box - This is a tool used by LANDesk Support that can track tasks in a timeline fashion and overall analize each step and the overall time to completion.
- Logs - As discussed below the IIS and console logs are especially helpful. A simple check of the time stamps may determine which step in which the slowness is happening. Also the console.exe.log in LANDesk 9.0 may report how long a particular query took to execute.
Resource issues may seem quite simple but in fact there is a lot more to this than simply checking drive space and the amount of available RAM memory. Here is a quick list of ideas to check on top of the obvious:
- Temporary Files - If temporary files are not cleaned out properly by the application creating them then they can accumlate at a steady pace. If left unchecked these files may fill up a particular folder and reach the 65,000 file limit and prevent any new temporary files from being created.
- 4GB memory limit and Physical Address Extension on Windows systems - I will save a lot of explanation on this setting and strongly recommend reading up on this subject on the web. A basic explanation is that an application may be limited in the amount of memory its using by design. Even though you have a server with 16gb of memory allocated all of the memory may not be availble to the application.
- I/O Reads and Writes - Windows Task Manager can be configured to display this setting. Excessive amount of reads and writes to an I/O will slow down the application as a whole.
Active Directory Issues
While console.exe is operating numerous checks for rights and scope will be performed and often times behind what the user can see. These checks by the console are not the same as logging into the Operating System so they shouldn't be compared to "I can login to the OS just fine". In LANDesk 8.8 and older verisons adding a user directly to the LANDesk Management Suite Group on the core server usually helps. However, in LANDesk 9.0 rights and user management has changed dramatically. Perhaps the best test overall for this problem is to create a temporary local user on the LANDesk Core with the same or administrator rights.
Database Issues and Optimization
Almost everything a console does will involve a table in the database to some degree. If the table(s) involved are corrupted, poorly indexed, or they contain a large number of rows then performance will suffer. This type of problem will typically affect only certain actions within the console. An example is the AlertLog table referenced in "Alertlog Table takes forever to load". The Logs Tool item will take a long time to load or fail to load completely.
- Database Corruption - See the last section on "Missing Features and Icons"
- Indexing - See "Reindexing LANDesk Databases"
- Excessive Row Size - Parsing through a database table containing a million rows will take some time regardless of the database server. Occasionally (for various reasons) the number of rows in a database table may reach a very large size. Details on which table will of course depend on the action being performed. If you are unsure of which table may be causing the issue then a SQL Trace should show how long a particular query took to run on each table. After the offending table is discovered a search in the community should be performed on the table or a case opened with LANDesk Support on triming the table properly. (Note: The "WSVulnerability" and "Logs" tables are especially known to very large sizes)
Internet Information Services (IIS)
Clients and Core Server alike are very dependant on IIS. The console will make calls to a Web Service or other function of IIS to perform certain tasks. If IIS (w3wp.exe) is too busy then these tasks will take longer than normal to execute.
- General Troubleshooting (Core Side)
- Reset .NET: "C:\Windows\Microsoft.net\Framework\v2.0.50727\aspnet_regiis.exe -i"
- Restart the core server or IIS Admin Service. (IIS Admin Service is a parent service for w3wp.exe and will also restart other web related services)
- IIS Optimization - Careful evaluation and testing of these settings should be performed. After a change is made a good test period of highs and lows in performance should report if the setting helped or hindered the problem. "Optimizing IIS 6.0"
- Over Scheduling of the Agent - Scheduling a Security Scan, Inventory Scan, Policy Checks, etc every hour would produce a lot of updated information but it will also add a lot of strain to IIS and the agent itself.
- Database Issues - Problems relating to the database are typically magnified when the request is going through IIS. It is recommended to follow the section above on "Database Issues and Optimization".
When a remote 32-bit console loads it will contact the Core Server and retrieve database connection information. After that most of the tasks performed by the remote console will access the database directly.
- DNS Issues - A problematic DNS server can cause numerous issues for a 32-bit console. A query that takes a long time can cause delays while an incorrect response can result in several different errors. A 32-bit console typically uses DNS a lot so testing both forward and reverse name resolution may save a lot of time.
- WAN Connections - A console can be a very busy application not only when communicating with the database but when communicating with other servers as well. Traveling through a WAN connection will greatly enhance any performance issues. Unfortunately by design not a lot can be done about this type of problem other then increasing the speed of the connection.
- Proxy Servers - Proxies typically don't cause slowness in the console however they are a source for communication issues and may prevent the core from reaching a client, another server, or the database. Proxies can be configured in many locations (see short list below). Using a program such as Wireshark to capture the routing of packets may display a previously unknown proxy or other server intercepting traffic.
- Internet Explorer
- An application running in memory