Code Signing is Important

In the last years, the signing the executables and libraries in a product has become common practice. This process protects the product from unauthorized tampering as any changes to a signed file can be detected by the signature becoming invalid. Consequently, code signing is an important protection against malware.

But the certificate protecting the signed code has a limited lifetime. As soon as the corresponding certificate expires, the signature cannot be considered to be valid as the vendor lost the credibility represented by the certificate. Usually, a vendor obtains a new certificate with a new lifetime and renews the signatures on the affected binaries. This is implemented by providing a hotfix of some kind for the product.

The Issue at Hand

EdgeSight 5.0 and 5.1 are currently suffering from the case described above – the certificate used for signing the code expires on the 25th of March 2010 (see this support article). Therefore, customers are forced to update to the latest versions (5.1.1 or 5.2.x). Unfortunately, this situation is hardly common knowledge so that I expect many angry calls to be logged with Citrix Support at the end of this month.

The Real Issue and my Plea

In my opinion, Citrix can hardly be blamed for the lifetime of a certificate – that’s just how they work. But I would have expected a proactive warning for customers. The articles in the Citrix knowledge base are of a rather informational nature and a warning can easily be overlooked. Especially, when the title (EdgeSight 5.0 and 5.1 Error: The archive is not appropriately signed) does not clearly state the effect of this message.

If a components suddenly stops functioning, direct communication is necessary. Publishing an article in the knowledge base does not suffice because many customers do not pay attention to these pages. And even if they did, the title needs to be descriptive in order to grasp the importance.

Side Note

Citrix offers a product lifecycle information which lists EdgeSight 5.0 and 5.1 to reach end of life on the 25th of March 2010.

In the course of this article, I will outline the problem of creating high quality, scalable images and inserting them into documents using Microsoft Word. Some of the issues are caused by the inherent differences between vector-based and pixel-based images as well as the image compression in Word. Fortunately, I am able to offer a solution to these obstacles.

A Short Introduction to Vector-Based Graphics

Vector-based graphic formats consist of a list of commands what kind of shape to paint at a certain position with pre-defined parameters. The advantage of this approach to drawing is the fact that the description of the image can be expressed in a very compact way and the image can be scaled to fit almost any size. Common formats include Scalable Vector Graphics (SVG) and Encapsulated PostScript (EPS) – the Portable Document Format (PDF) can even embed such vector-based graphics.

A loss-less compression can be applied to vector-based image to reduce their size without loosing quality. In fact, lossy compression does not make sense with these formats as drawing commands cannot be reduced in quality.

At some point in the process of using these formats, the image has to be converted to a pixel-based format to output it on a printer. This process involves deciding for an image resolution and size usually expressed in dots per inch (DPI). This step can become necessary when inserting the image into the document (as it is the case when using Microsoft Word) or when the document is translated into the printer language (as it is the case for LaTeX). Converting a vector-based to a pixel-based image inherently causes scalability to be lost because shapes are not expressed as drawing commands but as distinct pixels in the resulting image.

The size of pixel-based images can be reduced by using loss-less compression (eg. TIFF with LZW or Huffman) to remove redundancy without affecting quality. In addition, many formats leverage lossy compression to remove (supposedly) unnecessary details (eg. JPEG and PNG).

Why Not Stick To Vector-Based Images?

Although vector-based images obviously allow for greater detail when scaling or zooming, we are often forced to abandon a vector-based representation because applications only accept pixel-based formats – just like Microsoft Word 2007.

How to Prepare for Pixel-Based Formats

If the quality of an image or drawing is of the essence, carefully planning is required. For the sake of simplicity, the process of producing a document is iterated backwards:

1. Determine the quality of the output format. Let’s assume that a 600dpi printout is required.
2. Calculate the resolution of the image based on the width. Usually, an image takes 15cm in width to fill an A4 page of paper (portrait orientation). At 600dpi, the image should have at least the same number of dpi corresponding to 3600 pixels in width – roughly twice the resolution of Full HD ;-)

But there’s more to watch out for: try not to scale you image after converting it. If necessary use multiples of the original resolution.

Microsoft Word Image Compression

Microsoft has been offering a feature called image compression in many past and current versions of Word. It is a feature often looked upon benevolently because the overall size of the document is greatly reduced. This appears to be a pressing advantage but looking closely at the configuration options controlling the behaviour of the image compression, it is apparent that savings in size are tied to a loss of quality. The best quality offered by the image compression of Word is 220dpi.

What if this is not enough? What if an image contains details being lost at this resolution? Up to and including Word 2007, image compression cannot be turned off globally but only per document when “saving as”. Beginning with Word 2010, the image compression can be configured globally in the options of Word.

This difference in functionality causes documents without image compression to loose quality accidentally when carelessly using “save as”.

Alarming Behaviour of the Word Image Compression

In an article, Microsoft describes the behaviour of the image compression function. When image compression is enabled for a document, images are not immediately compressed upon saving. They are reduced in size (and therefore quality) when changes on the same page occur. This results in a document slowly shrinking as changes are incorporated into the document.

This alone is hardly troubling me but when considering that Word 2007 is missing the option to globally disable image compression, it may cause a significant loss in quality when saving a document with a new name and continuing to work on it.

Summary

Microsoft has helped many authors by building an image compression into Word. It reduces the size of images to a quality well-known to produce proper documents. Many articles on the net explain image compression and its blessings. But on the other hand, if you are required to produce high-quality image in your document, the image compression Microsoft Word may well be in your way – especially, if you are using current (non-beta) versions.

Performance Monitoring is Crucial

In the first part of this series, I have stated that performance monitoring is a crucial task for every administrator to guarantee the continuity of a service. It is always about the sizing of servers providing a specific service:

1. Is the service performing adequately for a known number of users?
2. Is the effect of peak working hours taken into account?
3. How many more users can the service take?
4. When do I have to scale the service to handle additional load?
5. How much more performance is required to handle additional users or additional requests?

There are many products on the market that support administrators in monitoring services. Nevertheless, a basic understanding for the importance as well as the relation between the subsystems of an operating systems is fundamental to successfully operate these products.

Recommended Metrics

In three individual articles, I have explained the most important subsystems (processor, memory and physical disk) and listed the crucial metrics to identify bottlenecks. The following table contains these metrics for all subsystems.

In addition to these metrics, the memory and the disk subsystem influence one another because of the page file providing virtual memory on the physical disk and, thereby, extending the scarce resource of physical memory built into a system.

In part 4, I have also mentioned three memory areas in the kernel (Non-Paged Pool, Paged Pool and System Page Table Entries) which are of special importance to the operation of a system.

32-Bit Terminal Servers are Easily Monitored

Currently many companies are using terminal servers and hardly any have migrated them to 64-bit yet. Although this is a logical step in the light of the attempts to save resources in data centers.

32-bit terminal servers are a much simpler case to monitor than 64-bit TS or even general purpose servers as they usually require physical memory to accommodate a high number of users.

Using PerfMon with a Database

In part 7 and part 8, I have moved on to some practical stuff. Performance monitor has become the first choice for performance monitoring as it is included in all Windows operating systems. Unfortunately, it is rather unknown that PerfMon can be configured to log metric values into a SQL database. This allows for many servers to store performance data in the same database and, thereby, simplifies the process of analyzing the data. Excel is a well-suited tool to produce graphical representations of the data collected on the individual servers.

Comparing EdgeSight and Resource Manager

Over the years, Citrix has offered a component with XenApp (formerly Presentation Server) for performance monitoring. This was provided free of charge for customers with an enterprise license for XenApp. Right now, we are in the middle of a migration from Resource Manager (included up to Presentation Server 4.5) to EdgeSight (included since Presentation Server 4.5). In the last part of the series, I try to shed some light on the differences between these two components.

Call for (Performance Monitoring) Topics

There are several topics concerning performance monitoring left out in this series – intentionally or carelessly. Is there anything you are missing or anything you are eager to learn about, drop me a line and I’ll strive to fill the space.

Two and a half years have passed and – finally – the project Parra tech preview offers a first (public) look at the new policy engine. In this article, I’ll have a closer look at the user interface and the handling of policies.

The New Design

In the current version of XenApp, the farm and server configuration is defined in the Access Management Console (AMC) whereas session policies are still configured in the Advanced Configuration Tool (ACT). From an administrator’s perspective, both sets of configuration parameters are very similar. Some are applied to the machine (farm and server settings) and other affect user sessions hosted on the server (session policies). Therefore, it makes sense to migrate all of these settings in Microsoft group policies instead of maintaining a separate engine with a very similar purpose.

But wait … aren’t session policies more flexible? Group policies cannot be applied to client names or client IPs. How does Citrix manage to migrate session policies without loosing this very important filtering flexibility?

The integration into group policies is not implemented in simple ADM templates but through an extension of the group policy editor. It now shows new nodes called “Citrix Policies” under computer and user configuration. The settings configured under this node are processed by a client-side extension (CSE) written for the group policy engine. Client-side extensions are a standardized method for adding custom handlers for group policy processing on the client. For instance, group policy preferences and folder redirection are implemented in CSEs by Microsoft.

Not only session policies have been moved to group policy but farm and server settings as well. The settings have been divided in the following manner:

• Computer Configuration: This section of a group policy contains all farm and server settings.
• User Configuration: This is where session policies are created and configured.

How Policies are Applied

A single group policy can contain any number of Citrix policies. When a group policy contains farm and server settings in the computer configuration, it is not automatically applied to all servers which the group policy is assigned to. This is caused by filters affecting how Citrix policies are applied. These filters can further narrow down on which servers the settings are enforced.

New Features

The following new features are implemented by leveraging Microsoft group policy:

• Farm and server settings are moved to Citrix Policies in the computer configuration of group policies.
• Filters for Citrix computer policies include the desktop group (used in VM Hosted Apps), the desktop kind (published, shared or private), a custom desktop tag or the organizational unit (which the server belongs to).
• Session policies are moved to Citrix Policies in the user configuration of group policies.
• Filters for Citrix user policies now include:
  • the desktop group (used in VM Hosted Apps) to which the users connects
  • the desktop kind (published, shared or private) to which the user connects
  • a custom desktop tag
  • the organizational unit (which the user belongs to)
• Known filters for Citrix user policies: access control (for connections through Access Gateway), client IP and name and users.
• Servers cannot be used for filtering Citrix user policies anymore. There are removed in favour of server group which can be created by administrators using AMC.

The User Interface

Finally let’s have a look at the user interface:

Citrix has extended the group policy editor to include a new node called Citrix Policies under computer and user configuration. Both of these nodes show the same layout in the content pane. The top half shows a list of Citrix policies contained in this group policy and the bottom half displays detailed information (settings and filters) about the policy selected above.

A new policy is created through a wizard in three easy steps:

1. Configure the settings to be contained in the policy:
   
2. Select how the policy is applied:
   
3. Choose whether to enable the policy:
   

After a policy has been created, it can be configured from the content pane of the group policy editor. The summary tab displays all active settings and filters which can be modified and removed with a single click:

On the settings tab, new configuration options can be added to the policy from the full list with or without categories:

On the filters tab, configured are displayed and new filters can be configured:

Summary

Let me tell you that the group policy integration in project Parra tech preview really rocks.

Citrix gets rid of the outdated Advanced Configuration Tool. Presentation Server 4.5 and XenApp 5 moved most of the administrative tasks to the Access Management Console so that only policy management remained in the old Java-based console. It became increasingly annoying to open a second console and access separate dialogs to configure settings and filters.

Now, policies (Citrix and Microsoft based) are configured in a single console. Project Parra finally makes policy management fun. Thank you, Citrix!

With the dawn of Office 2010, one feature caught my attention: the new version of Microsoft Office (now in beta and available here) is announced to allow for ribbons customization through the user interface.

Let’s have a closer look at this feature and how it compares to the InstantRibbonChanger.

Customizing Ribbons through the UI

In all application in the Microsoft Office 2010 beta suite, ribbons can be customized by right-clicking on a ribbon and selecting "Customize the ribbon". A new dialog opens which reminds of modifying the quicklaunch bar but now allowes for ribbons to be changed (see here for a detailed description):

• Add and remove ribbons
• Enable and disable ribbons
• Add groups of controls
• Add controls to ribbons or groups

This all seams really cool but I am missing some important features when comparing the options to the InstantRibbonsChanger.

No Control Over Button Size

The size of buttons added to any ribbons is chosen by the application. If you are an experienced user and intend to group buttons from regularly used ribbons into a single custom ribbon, this will be causing you some pains. Only placing many buttons on a ribbons of using a smaller window size will cause the application to downsize buttons.

No Button Groups

There are many buttons with a similar or related function. In pre-defined ribbons, such buttons are grouped like left, centered and right alignment. When customizing a ribbon, only pre-defined elements of existing ribbons can be added.

No Custom Keyboard Shortcuts

When buttons are added to ribbons they are automatically assigned a keyboard shortcut. Unfortunately, there are many collisions as there are merely 26 distinct characters causing keyboard shortcuts like "Y2". These shortcuts cannot be customized through the user interface.

Continue to Use the InstantRibbonChanger

If you require any of the features presented above, you will have to continue using the InstantRibbonChanger. As it uses RibbonXML – the markup language for ribbons in Office – it is able to modify ribbons in Office 2010 as well.

This article is not meant to compare all available monitoring solutions as both fit in the same niche on the markets. My goal is to urge everybody to drop Resource Manager in favour of EdgeSight.

Introducing both solutions

Resource Manager is a component shipping with Presentation Server for a long time. By installing Resource Manager on a XenApp server, an additional component is responsible for collecting performance data on all servers. This data is aggregated on a daily basis and collected by the Farm Metric Server. This role has a primary and a secondary instance to ensure its availability. The Farm Metric Server stores the data inside the configured database through the Database Connection Server represented by a XenApp server.

EdgeSight has a very similar design. Although data is also collected on all servers, this is done by an agent independent of XenApp which allows for additional platforms to be monitored, e.g. endpoints. The XenApp agent is responsible for collecting performance data and uploading the data to the EdgeSight server on a daily basis. The EdgeSight server stores the data provided by the agent inside its database. The web-based console offers a large number of reports rendered by MS SQL Server Reporting Services.

Architecture

After introducing the architecture of both solutions, this category presents some important properties of the components involved.

• Agent. Both products require some kind of software to collect data and upload it into the database. In the case of EdgeSight, there is an agent running as a separate process. Resource Manager does not operate through a distinct process but rather integrates into XenApp.
• Database. Resource Manager as well as EdgeSight require a database to store the collected data. Both implement a relational database schema to prevent redundant data from bloating the database.
• Dependencies. Resource Manager does not rely on any additional components except for the database. EdgeSight requires Microsoft SQL Server Reporting Services for data visualization (see separate category below) and Internet Information Services for the administration interface (see the category about management below).
• Client Monitoring. Only EdgeSight is able to monitor devices apart from XenApp. A separate endpoint agent is provided for client devices but can also be installed on servers.
• Multi-Tenancy. EdgeSight allows multiple customers to be managed through the same infrastructure. Configuration and reports are separated into companies with independent authentication realms. Resource Manager does not offer multi-tenancy.

EdgeSight introduces more prerequisites than Resource Manager and is, therefore, more work to set up. But the architecture allows for additional features like client monitoring and multi-tenancy.

Management

This category regards the administrative features of both monitoring solutions.

• Centralized Configuration. Although Resource Manager is managed from a single instance of the console (CMC / PSC / ACT / AMC), new servers do not receive a default configuration automatically but rather through a manual process initiated from the console. EdgeSight allows several sets of configuration data to be bound to departments. Whenever a new agent is added or adds itself to a department, the configuration assigned to the department is applied automatically. This effectively speeds up rollouts as new agents do not require manual intervention.
• Management Console. While the administration of Resource Manager is integrated into one of the consoles shipped with Presentation Server / XenApp, EdgeSight uses a web-based console only requiring a web browser and network access to the EdgeSight server. For obvious reasons, this architecture implies less restrictions for the administrator as EdgeSight does not require a components to be installed on the administrator’s machine.
• Abstraction Layer. As Resource Manager is integrated into the XenApp console, it abstracts from individual servers by utilizing the server folders offered by XenApp. EdgeSight isolates customers into companies (see multi-tenancy above) and, inside a company, groups servers into departments organized as a tree. For agents monitoring XenApp servers, EdgeSight automatically creates folders for the farm and all server folders when adding the agent.
• Automation. Resource Manager cannot be fully automated. Manuel intervention is required to replicate the configuration of an existing XenApp server to apply it to a new one. Due to the central configuration of EdgeSight, only the installation of the agent needs to be automated. This is fully documented in the administrator’s guide.
• Authentication / Authorization. To be able to access Resource Manager, a XenApp farm administrator is required. Although this poses a dependency between XenApp and Resource Manager, permissions to access Resource Manager are managed through the same console. The account used for authentication cannot be entered explicitly. EdgeSight allows administrators to authenticate through a built-in user management or through active directory. There is not single sign-on.
• Delegation. Access to real-time performance data collected by Resource Manager is possible through the console and can be delegated based on server folders. EdgeSight allows for custom roles and for them to be assigned based on departments.
• Integration with Upstream Monitoring Solution. Both product allow for alerts to be sent to an upstream monitoring solution using SNMP. In addition, EdgeSight is able to call custom scripts or tools to connect to other products.
• Alerting Administrators. Both solutions implement alerts to be sent to the administrator by email. In addition, Resource Manager allows for text messages.

EdgeSight is inherently easier to manage concerning the configuration, the rollout of new agents and the automation of the monitoring infrastructure.

Data Collection

The following bullets discuss how the products collect data and what data is obtained from the monitored systems.

• Default Range of Collected Metrics. Both solutions collect a wide range of performance metrics sufficient for most needs in historical as well as real-time analysis.
• Collecting Custom Metrics. In contrast to EdgeSight, Resource Manager can be configured to collect custom performance metrics offered by Windows. Unfortunately, it is also limited to these performance metrics and does not allow other data to be collected.
• Analyze Event Log. Only EdgeSight allows for the Windows Event Log to be parsed for specific items and generate alerts.
• Application Crash / Fault / Hang. Only EdgeSight recognizes misbehaving applications. It reports on applications being unresponsive, having crashed or produced an error dialog.
• Asset Management. Only EdgeSight collects asset information about the underlying system.

Concerning data collection, EdgeSight is able to score although it does not collect custom performance metrics. It rather provides a sensible set of aggregated counters by default. In addition, EdgeSight collects and analyzes more important data than Resource Manager.

Data Visualization

Although collecting data from different source on a system is a very useful feature, a performance monitoring solution must be able to visualize the data. Otherwise, humans have trouble taking in the important details.

• Data Visualization. Resource Manager offers a very small set of reports to analyze the data collected on the servers. Unfortunately, these reports do not visualize all the data present in the database. EdgeSight incorporates a huge number of historical and real-time reports to span the whole range of the collected data.
• Relational Database Schema. Both solutions implement a relational database and, thereby, avoid storing redundant data.
• Custom Reports. Based on the relational database schema, custom reports can be created for both solutions. EdgeSight is able to integrate additional reports into its console to offer a consistent look and feel.
• Dashboard. Only EdgeSight offers a dashboard for analyzing custom real-time data across several systems.
• Real-Time Reports. Both solutions allow the collected data to be analyzed in real-time by directly connecting to specific systems. Resource Manager even displays an automatically updating graph of the real-time data.
• Output Formats. Resource Manager only allows HTML-based reports to be generated. As EdgeSight is built on top of the SQL Server Reporting Services, reports can be exported to PDF, HTML, CSV, XML or Excel.
• Subscriptions. Only EdgeSight offers report subscriptions. They can be sent via email or stored on a file share.

EdgeSight clearly dominates the category about data visualization due to the numerous reports visualizing all the collected data.

Conclusion

Both monitoring solutions are important additions to such a XenApp environment. The fact that EdgeSight offers many reports to visualize the collected data makes it better suited. Administrator need to be able to retrieve the necessary data immediately instead of building a new report every time they require an additional piece of information.

Citrix has been offering Resource Manager as part of XenApp Enterprise Edition for a long time. But early in 2009, a basic edition of EdgeSight was released to offer customers an alternative to Resource Manager. The fully functional edition is only available in XenApp Platinum Edition. Licenses for endpoint agent must be purchased separately for both editions of EdgeSight.

Overall, I recommend that you take a look at EdgeSight if you have already licensed XenApp Enterprise Edition or above as it offers a more advanced solution for monitoring the environment.

Excel offers a feature called pivot tables. It allows some data mining either on a local data set contained in an Excel sheet or on a database which Excel is connected to. Therefore, this article describes how to create a connection to the database and create nifty charts using Excel.

Creating a Database Connection

First, the data needs to be pulled into Excel. Instead of pulling tables or the result of a query into a sheet, we will configure a data connection to display results. Duplicating data into Excel hardly makes sense because it unnecessarily bloats the file.

On the data tab, Excel offers several methods for reading data from different sources. We will use the "From SQL Server" button to create a connection to the Performance Monitor database.

In the first dialog, enter the server name and click next. The following step of the wizard select the relevant database (in my case, it is called PerfMonDB) and uncheck the option to "Connect to a specific table" because we do not intend to use one of the tables. Then click "Next" and "Finish".

In the next dialog you will be asked to select a table. At this point, it is the selection you make is insignificant because we will use a SQL statement later on.

Before any data is inserted into your Excel sheet, the following dialog allows the data connection to be customized. Select "PivotChart and PivotTable Report" and click "Properties" to insert a custom SQL statement.

On the "Definition" tab of the new dialog, select "SQL" to be the "Command type" and page the following SQL statement into "Command text". Then click "Ok".

After closing the dialog, Excel may ask you to confirm the change of the connection definition. Please confirm this by clicking "Yes".

Using the PivotChart

You have now created a blank PivotTable and PivotChart report with a direct connection to your Performance Monitor database. All this is achieved without pulling in the actual data from the database. You Excel sheet should look similar to the following screenshot.

The Excel window now contains several new elements: a PivotTable area on the left, a blank PivotChart accompanied with a filter pane in the middle and a PivotTable field list on the right. I will now expand on the PivotTable stuff but rather demonstrate how to use the PivotChart as a dashboard for analyzing the performance data contained in the database.

First, we will move the PivotChart to a separate sheet to have a well-arranged workspace. Right click on the blank PivotChart, select "Move Chart" and choose "New sheet" in the dialog. After attaching the filter pane to the right side of the window, I configured the PivotChart to analyze the performance database:

1. Drag the DisplayString and MachineName fields to report filters
2. Drag the CounterName to the legend fields
3. Drag the CounterDataTime to the axis fields
4. Drag the CounterValue to the values box

After some adjustments to the layout, I arrived at the PivotChart displayed in the screenshot below. Without much hassle, I am able to view the counter values from the database and create a nice visual representation.

Using the filter pane allows you to filter which data is actually displayed in the PivotChart. If your Performance Monitor database contains several series of measurements for different machines, filtering focuses the PivotChart on the exact amount of data you intend to view from the database.

Most of you have probably used Performance Monitor before. It allows you to monitor performance metrics (local and remote) in real-time and to log performance data from multiple machines for later analysis. In this article, I will focus on the latter because collecting and analysing performance data from multiple machines is a time consuming task.

For the sake of this article, I assume that your are familiar with Performance Monitor and that you know how to create a data collector set. The following example was built on Windows Server 2008. But earlier instances of Windows do not differ greatly.

How to Log to a Database

It is not very well-known that Performance Monitor is able to log the collected data to a SQL database. There are several advantages to this method:

• Several systems log to the same namespace. No more combining dozens of CSV files.
• A single database can contain several independent data sets.
• A single database can contain data from several machines.

Let me quickly outline how to log performance data to a SQL database. First, create a database on the SQL server. In my scenario, this database is called PerfMonDB. Next create a system data source pointing to your database – I called this PerfMonDSN.

After these preliminary steps, we can finally configure a new data collector set which I called PerfMonDataSet. The DataCollector01 inside PerfMonDataSet requires the following settings to successfully connect to the database. These are displayed in the two screenshots below.

• On the tab “Performance Counters”, you need to add the required performance counters to the data collector and configure the database connection:
  • The log format needs to be set to “SQL” for this scenario to work.
  • The data source name is to be set to PerfMonDSN to connect to the database configured in the preliminary steps.
• On the tab “File”, you configure the file name saved inside the database. This uniquely identifies a single run of the data collector set:
  • The log file name is a custom name for the data set. I called this PerfMonLog to distinguish this name from the others selected above.
  • The file name format allows some predefined variables to be appended to the log file name. This helps to identify individual runs of the same data collector set.
  • By activating the check box the log file name is prefixed with the computer name executing the data collector set.

The settings above result in a unique name identifying every single run of the data collector set.

Database Schema

When Performance Monitor writes to a database, three tables are involved in the process: CounterData, CouterDetails and DisplayToID (see screenshot below).

The table CounterData contains the collected data for the selected performance counters. It also references the other two tables to identify which counter and which data set the data belongs to. The screenshow below shows the relationships between the three tables.

The following screenshot shows the columns of the table DisplayToID and some example data for two runs of the above data collector set. Expect a new line for every execution of every data collector. It identifies the individual runs by the following (selected) fields:

• A unique ID called GUID – this identifier is used to refer to a certain data set from every record in CounterData
• The DisplayString corresponding to the example file name above
• The time when the log was started and stopped (LogStartTime and LogStopTime)

The table CounterDetails contains a description of the performance counters logged in the database. These records are independent of the data set and can be used from several data sets at once. These details contain the following information:

• A unique ID called CounterID – this is used to refer to a certain performance counter from every record in CounterData
• The MachineName identifies the machine from which the performance counter is pulled
• The ObjectName identifies the display name of the object to which the performance counter belongs to
• The CounterName identifies the counter which is collected
• The InstanceName identifies the instance of the counter which is collected
• (The other fields are not particularly interesting.)

If, for example, you have added the counter Processor(_Total)\% Processor Time this resolves to the following: ObjectName is Processor, CounterName is % Processor Time and InstanceName is _Total.

The last table called CounterData contains the data for all counters collected in individual runs of data collector sets. The following fields are relevant for an analysis:

• The GUID referencing the data set (in DisplayToID) which the counter data belongs to
• The CounterID referencing the counter details (in CounterDetails) which the data belongs to
• The CounterDateTime represents the time stamp at which the data was collected
• The CounterValue contains the value collected at the specified point in time

How to Analyze the Data

In the next part of this series, I will demonstrate how to use Excel to efficiently analyze the contents of the Performance Monitor database.

Windows Server 2008 R2 has more than 80 features available to the administrator to supplement the numerous roles. But many of these features have strange names making them close to impossible to understand.

Nicki has already published 10 videos on a YouTube channel called R2FeatureTalk. Watch me talking about Network Load Balancing – and I will be involved in several more.

Kudos for this great idea, useful content and funny introductions.

When XenApp is installed on a server running the Internet Information Services (IIS), the installer offers to activate port sharing between the XML service and IIS. What this actually means is that the XML service is not setup as a system service but as a DLL inside IIS.

How the XML service works

The XML service consist of several DLLs responsible for the individual services. The following table describes the files involved with the XML service.

If a system service is used for the XML service, these files are used from their original location (%ProgramFiles%\Citrix\system32). But this is not the case when it is provided by a DLL inside IIS, because the files are copied to a separate directory (%SystemDrive%\Inetpub\Scripts).

Why Using IIS is Dangerous

Don’t get me wrong – using IIS is not dangerous in general. But rather having the XML service inside IIS is. There are two major pitfalls:

• Customizing the configuration of the XML service inside ctxsta.config needs to be performed in the correct location. Many installations require the ID of the STA to be set to a constant value. This only works, if the correct configuration file is used.
• When IIS is uninstalled from the system, the XML service can no longer function because IIS was responsible for connections to the designated port. You may well cause an outage of your infrastructure because Web Interface sites may not be able to authenticate users and enumerate applications (which is done through the XML service).

Fortunately, there is an easy way out of the second problem. Citrix offers a tool to change the port of the XML service called ctxxmlss.exe. This tool ships with all versions of XenApp and is located in %ProgramFiles%\Citrix\system32.

Citrix also provides an article describing this tool but misses to state explicitly that the following command also creates the system service on port 81 – in addition to changing the port of an existing XML service:

This command makes you independent of IIS with regard to the XML service.

Why XenDesktop is affected as well

The issue also occurs on the Desktop Delivery Controller (DDC) of XenDesktop because of the automated installer. It does a wonderful job by taking care of all the gory details of setting up the DDC, e.g. terminal services are installed automatically. But it also installs the XML service with IIS port sharing enabled.

Unfortunately, this causes the same issue described above – and is resolved by the same command line executed on the DDC.

References

Explaining and Changing the Citrix XML Service Port (http://support.citrix.com/article/ctx104063)

How to Configure the XML Service to Share with IIS (http://support.citrix.com/article/CTX107683)