Getting Started with the Altiris Profiler to Troubleshoot the Altiris Web Console Issues
- Starting the profiler for the first time
- Trace filter options and populating categories
- Setting a filter for Web Application Requests
- Preparing the console to capture the failure
- Analysing the captured data
Sometimes errors do occur on the Altiris NS console (for NS core or Solution pages) and the error messages are not always self explanatory. In this article we will review how to get started with the Altiris Profiler to troubleshoot such problem.
!Note: All images below are scaled down to the lowest size (medium thumbnails) to ensure to keep the document easy to navigate. Click on the image if you want to see it on a new window or tab (it opens in target _blank).
Starting the profiler for the first time
The Altiris Profiler is part of the Altiris Diagnostics tool kit delivered with the Notification Server SP3 executable. It is installed during the base Notification Server installation from "%programfiles%\Altiris\Setup Files\NS". The MSI package is (guess what) named Diagnostics.msi :D.
So if your base install worked without any problems you'll find the profiler on the Start Menu under "All programs > Altiris > Diagnostics".
If you open it for the first time and have not run the Altiris Logviewer (which I would say is not possible - as this is the starting point to finding and resolving any problems on Notification Server) it is possible that an update is available (if you have access to the internet from the NS). It is highly recommended to update the tool kit, as many features have been added since the SP3 release was packaged.
Once the update installed you will have to get back to the start menu to start the profiler again (sorry, the updater doesn't have an auto-restart program function) and you will be greeted by the Profiler Wizard. I strongly suggest to politely decline the offer to run with it, and possibly to prevent it from appearing again by unticking the "Show this wizard at startup" option as shown below (and if you are curious about the wizard you can invoke it from the menu or from its tool bar icon),
One last step before we are ready to run the profiler (if it was never run before) is to restart IIS in order for the code hooks in the Altiris web-applications to be enabled. The profiler detects this on its own and a dialog box appears asking you whether you want to run iisreset or not. If you need to profile code running in asp.net (and the w3wp processes) you must click yes or raise a change request or down time to reset the web server. Once this is done you are ready to run the profiler to its full capabilities.
Trace filter options and populating categories
So before we can actually run a trace I must acquaint you to your next best friends on the profiler, alias the Code and SQL filters. The code filter dialog box can be found on the menu or directly accessed on the tool bar as shown below. As you can see in a clean installation the code filter categories is totally empty. This will be populated later on.
The SQL filter dialog box is located on the menu and toolbar, in between the clear option (left hand side) and Code Filter (right hand side). It is simpler than the code filter but it is equally powerful.
As stated above the Code categories view pane until the profile trace as run. So let's go clicking on the Start profiling button (the little play button on the tool bar painted in green shades). As you seen the profiler view pane (code tab) populate you can now return to the code profiler to see the newly added categories:
You can let the profiler run for a little while in order to get a good amount of categories added. In production systems this generally doesn't take very long.
Setting a filter for Web Application request
With a category filter nicely populated we can now get into the real work: profiling the section of code that interest us in this case and find out exactly what is happening (or not happening in case of a failure).
Today we are interested by the Sequential Software Delivery Task page that doesn't load grid information for a customer of mine. So we need to setup a code filter to ensure only the Altiris console related information will be captured. This is done by unsetting all the categories (click once on the category tree root to select all and a second time to un-select) and selecting the AltirisWebApplication>Request entry in the tree. This is illustrated here.
Then you need to change some of the default code capture behaviour. Make sure you click the "Only apply category filters to top level code blocks" (which I had missed out on my first run, so I cleared the trace and set the filter properly before restarting it). This is extremely important as it ensures that sub-tasks contains within the AltirisWebApplication>Request are captured (so we can examine them and learn from the trace data). The tick box you need to select is highlighted in green below:
Preparing the console to capture the failure
Right, so before we can start the real trace we need to go to the console and prepare to click on the right button as the trace is started. The profiler is very useful but it can be easily overwhelming if you capture too much data and don't know exactly what you are looking for (unless you are using it for trending, but this is another story). So prepare the console, go back to the profiler to start it (code and sql trace) and click on the page or menu entry that will cause the failure.
In this example I have prepared myself by selecting a random Sequential task wasn't my target. After I started the profiler I click on the next one up that interested me and right after it loaded I went back to stop the profiler.
Analysing the captured data
With the data in the box comes what can be sometimes the most difficult part of the job. Understanding what is or isn't happening. On my test system the standard workload is very low so I could capture the event that I needed quite rapidly, but in a server with active user you most likely will have to resort to using the search function (at the bottom) to find the event you want to dissect.
We can see on this first view of the captured event that on the rawUrl property that it is a request to 'Altiris/SWD/SWDWin32/SequentialSWD/edSequientialSWDTask.aspx'. The next few entries are self explanatory, but it's worth noting the ExecuteReader showing timing of 12,010.0 / 21. This indicates the SQL queries within this request took 12 seconds to complete, whilst the code sections executed in 21 ms (milli-second). Next we have a "method" icon that can expanded to show the Nested SQL (see next image), a Log\ReportTrace event, a couple of DBConnection (open/close and an Item\GetITem execution.
Expanding the "Nested SQL" we can get details on the SQL queries that were executed by the NS to full-fill this web request. If you double-click on any of the lines you will be taken to the SQL view tab on the main pane where you will be able to see more details (specially if the SQL query statement is a multi-line entry). You can see here that a lot of checks are done to retrieve and apply security settings to objects and we can also recognise the standard collection queries right at the end (selecting the main collection and adding computers from the include collection(s) and removing computers from the exclude collection).
Finally, browsing down the execution tree we can see that data is loaded from the query results onto the grid control before the information is sent back to the console in the http response. This is where my customer is having an issue, and I hope that getting a similar trace will help us see what is not working.
The Altiris Profiler is a very good tool that helped me resolving many issues in the past, and no doubt will continue to help me resolve problems in the future (and I hope this will be true no later than tomorrow!
I wish you all to have good profiling sessions ;-)