Important things to consider before replaying a Citrix Script in by lonyoo

VIEWS: 756 PAGES: 21



Author: John Lyttle

Please Note: This document has been designed to enhance troubleshooting techniques when dealing with Citrix problems and errors in SilkPerformer. The purpose of this white paper is to provide users with some background knowledge of the Citrix Environment as well as providing insight into SilkPerformer‟s Citrix support. The document does NOT provide information on how to Record; Replay and Customise a Citrix BDF Script in SilkPerformer. For detailed information on how to do this please refer to the SilkPerformer tutorial which is located in the documents folder of the SilkPerformer MMC install.

1) What is Citrix and how does it work ? Citrix is a set of commercial server software from Citrix Systems that enables multiple users to launch applications on a remote server and view and interact with the application as if it were running on the user's own computer. Citrix brings the application's user interface, audio, and print jobs to the user's computer in a way that is completely transparent or "seamless". The architecture of a Citrix MetaFrame environment normally takes the shape of numerous Citrix ICA or NFUSE clients connecting to a Citrix Server farm. A Citrix server farm is a group of Citrix servers managed as a singled entity. Servers in a farm share some form of physical connection and a common base of user accounts. What is ICA Independent Computing Architecture (ICA) is a Windows presentation services protocol from Citrix that provides the foundation for turning any client device into the ultimate thin client. The ICA technology includes a server software component, a network protocol component, and a client software component. On the server, ICA has the unique ability to separate the application's logic from the user interface at the server and transport it to the client over all of the standard network protocols IPX, SPX, TCP/IP etc as well as over popular network connections dial-up, ISDN and ATM etc. On the client, users see and work with the application's interface, but 100% of the application logic executes on the server. The ICA protocol transports keystrokes, mouse clicks and screen updates over standard protocols to the client, consuming less than 20 kilobits per second of network bandwidth. Role of ICA ICA is highly efficient client in that it only allows only keystrokes, mouse clicks and screen updates to travel the network. Thus as a result, applications consume just a fraction of the network bandwidth usually required. This efficiency therefore enables the latest, most powerful 32-bit applications to be accessed with exceptional performance from existing less powerful PCs. Citrix is one of the most efficient examples of a Thin Client/ Fat Server system. Using Citrix ICA To use Citrix you need to have an enhanced version of Windows NT 4.0 (Terminal Server Edition) or Windows 2000/2003 with Terminal Services Installed; as the Citrix MetaFrame server software (for Windows) runs on top of Microsoft Terminal Server. Microsoft Terminal Server is kind of a subset of Citrix and some portions of Terminal Server were even written by Citrix for Microsoft. Once Citrix MetaFrame has been installed you can allow multiple users to run multiple applications on the Citrix Server at the same time. When you run applications on the Citrix Server the screen shots are sent to your computer and, in return, your keyboard input and mouse movements are sent to the Citrix Server.

Citrix operates by intercepting GDI (Graphical Device Interface) calls from Windows application running on the server. These calls are then translated in to commands to send to the client to draw. The bits of graphics to be drawn are captured and sent as "glyphs" or pieces of images that can be pieced together and can often be recycled and cached on the client computer (bitmap caching); if the same image appears on the screen there is no need to resend the graphic. This gives viewing an application through Citrix about the same loading efficiency as a web page. Although Citrix can use the HTTP protocol among others (TCP/IP etc), it is not a "web" application or web based. In fact no web browser is required to run a Citrix Client or Server.

Real World Scenario of how Citrix is deployed in a Network

Applications running on Citrix's MetaFrame server-based software can be accessed by: 1) Any local or remote client (including UNIX, Macintosh, and Windows clients) 2) wireless devices, (3) network computers (4) terminals. No software resides on the client, and screen updates and keyboard/mouse movements are the only data passed back and forth on the network connection.

How fast a connection do I need to access a MetaFrame server? The Citrix ICA protocol is very efficient, requiring a small amount of network bandwidth (520kbps). ICA is also robust enough to continue operating even if the bandwidth becomes more limited. This is extremely efficient when you compare the bandwidth required by other client applications running across the network.

What are the Advantages of using Citrix? Reduces the cost of deploying applications i.e. it frees up clients so that they do not have to install applications on numerous client machines. No need to perform expensive upgrades of clients as all the processing for the application you are accessing is done on the Citrix servers. There is a significant cost saving in that all upgrades of applications is completed in a centralized location (Citrix Servers), thus reducing the cost of upgrading applications in remote locations. Save on bandwidth. Citrix (and Terminal Server) can run decently over a 56k modem. As the network operations are all done on the server; therefore the client plays no part in uploading or retrieving data from other servers such as a database. Connect to your application from anywhere. Citrix can be used in an internal network and over the Internet. No web browsers are required for access. The print feature on a Citrix Server works as if the user is printing from an application running on their computer. When a Citrix client connects to a server it "auto creates" printers on the server for each of the local or locally mapped printers. Scalability, Citrix is a very scalable environment, which allows the support of a small number of users to a very large number of users with the use of multiple load-balanced server farms.

Citrix Case Study: The link below is a case study which explains how a company with a high number of remote staff managed to reduce cost, bandwidth and staff time by implementing Citrix MetaFrame Server as a centralized solution.

Citrix NFuse Citrix NFuse is a Web Client version of Citrix which allows a user to access an application by first accessing an NFuse Web Server which in turn accesses the Citrix MetaFrame Server. To run NFuse a user must have access to a Web Browser such as IE and have the Citrix ICA client installed. How Citrix Communicates The communication between the client workstation and NFuse Web server occurs by default on port 80 of the NFuse Web server. The communication between the NFuse Web server and the MetaFrame/XML server occurs on the port number specified by the administrator during installation of the Citrix XML service. According to official documentation the communication between the client workstation and the MetaFrame server occurs by default on TCP port 1494. I have confirmed this here in support by using the tool TCPView to verify that the Citrix Servers in Austria and Belfast are listening on the TCP port 1492. Client workstation --- > NFuse Web server -- > MetaFrame/XML server The client workstation passes user credentials to the Web server using the NFuse logon page. The Web server receives the credentials and passes them to the MetaFrame/XML server. The MetaFrame/XML server determines which icons the NFuse user should receive based on the user's NT-based group membership. Client workstation < -- NFuse Web server < -- MetaFrame/XML server The MetaFrame/XML server sends the icon information back to the Web Server, which then displays the icons on a Web page in the user's browser. Client workstation -- > NFuse Web server -- > MetaFrame/XML server The user clicks on one of these application icons. This click by the user is a request by the workstation to launch that ICA application. This request is sent to the Web server and the Web server passes on this request to the MetaFrame/XML server. The MetaFrame/XML server communicates with the other MetaFrame servers on the subnet to determine which MetaFrame server the user should be connected to. The MetaFrame/XML server then gathers this information and sends it back in the next step. Client workstation < -- NFuse Web server < -- MetaFrame/XML server The /XML server sends the application information to the Web server. This connection information is entered into a file called Template.ica. When the Template.ica file contains this connection information (including the IP address of the MetaFrame server), the workstation downloads the ICA file. Client workstation --- > MetaFrame server When the workstation has the ICA file, it launches an ICA connection based on the information within it. The network traffic generated now is ICA traffic. This traffic is displayed in more detail below.

What are the typical Performance Issues a Citrix User will encounter? The purpose of Performance Testing a Citrix Server using SilkPerformer is to identify any Performance related problems before the Server is deployed in a live environment. Using SilkPerformer to run a loadtest a user can identify if any problems occur under load conditions and then subsequently act to remedy the problems by tuning the Citrix Server. Typical issues which can occur on a Citrix Server could be     Logons are too slow. User interaction with applications is slow. How many users can access the server before performance degrades. The server erratically hangs, spikes, pauses, freezes under load.

It is important to note that when a user is running a test against an application which is launched on a Citrix Server; that the end goal of the test should be to test the performance of the Citrix Server as opposed to the application running on the Server. The reason for this is because the performance of an application which runs on a Citrix Server will be very much dependant on the performance of the Citrix Server which is hosting the application. The load testing of an application through a Citrix environment would not enable an end user to accurately gauge the performance of the application. The application should be tested independently of the Citrix environment.

2) Recording the Citrix ICA Client in SilkPerformer For recording Citrix traffic, SilkPerformer has introduced a specially designed Citrix Recorder, which is launched in conjunction with the normal Recorder during the record process. To understand why this happens we first have to understand what occurs when a Citrix ICA connects to a MetaFrame Server. When the ICA Client “Program Neighbourhood” is launched a user can connect to a remote Citrix Server and this spawns subsequent processes. Below is a table which shows in sequential order the processes which are launched when a user connects to a Citrix Server environment. Executable Pn.exe | Wfcrun32.exe | Wfica32.exe Program Description Program Neighbourhood Remote Application Runtime Citrix ICA Client Engine

In SilkPerformer when the “Model Script” button is pressed the SP Recorder is launched. This launches the Citrix Recorder which spawns the Citrix Client Engine. The Citrix client engine connects to the Citrix server. The table below shows in sequential order the processes which are launched when a user connects to a Citrix Server environment during the Record process.

Executable PerfRun.exe | PerfIcaRec.exe | Wfica32.exe

Program Description Normal SilkPerformer Recorder Citrix Recorder Citrix ICA Client Engine

During the actual record process the Citrix Recorder will record the following client side actions Key Strokes: Pressing of keys on the keyboard for inputting text or issuing commands. These actions are recorded using the Keyboard group of functions in SilkPerformer. CitrixKey CitrixkeyDown CitrixKeyUp CitrixKeyString Mouse Movements: Moving the mouse cursor across the screen or executing a single or double mouse click. These actions are recorded using the Keyboard group of functions in SilkPerformer. CitrixMouseButtonDown CitrixMouseButtonUp CitrixMouseUp CitrixMouseDblClick, CitrixMouseMove

Window Functions These are functions which have less to do with a particular user action but are recorded as a consequence of how a Window appears on the screen for example the Window Size, Position, Style, Id etc. What to consider before performing a Citrix Record in SilkPerformer? Just like recording against a web based application a user should clear out the cache before performing a Citrix record in SilkPerformer. To clear the Bitmap Cache from the Citrix Client do the following: ICA CLIENT | TOOLS | ICA SETTINGS | BITMAP CACHE | Check “Clear Cache Now”. From research I have found that on occasions if a user has not deleted the bitmap cache that synchronization functions will be recorded before the Citrix Logon has occurred; for example consider the following BDL Before Cache was deleted:
CitrixInit(800, 600); CitrixConnect("", "support", Decrypt("9lVuBce/HQ=="), "",COLOR_256); hWnd5 := CitrixWaitForWindowCreation("", MATCH_Exact, 0x96840000, -2, 572, 804, 30); hWnd6 := CitrixWaitForWindowCreation("ICA Seamless Host Agent", MATCH_Exact, 0x94C800C4, 0, 0, 390, 223); CitrixWaitForLogon();

After Cache was deleted:
CitrixInit(800, 600); CitrixConnect("", "support", Decrypt("9lVuBce/HQ=="), "",COLOR_256); CitrixWaitForLogon(); hWnd5 := CitrixWaitForWindowCreation("", MATCH_Exact, 0x96840000, -2, 572, 804, 30); hWnd6 := CitrixWaitForWindowCreation("ICA Seamless Host Agent", MATCH_Exact, 0x94C800C4, 0, 0, 390, 223);

When recording against Citrix NFuse environment it is highly recommended that a user deletes both the Citrix bitmap cache and the browser cache to ensure that a correct record can occur. ICA Client Versions which are supported SilkPerformer 6.6 has been fully tested and supports Citrix ICA Client (Versions 7.0 and 7.1). The Citrix 8.0 client is currently not supported as it contains a number of bugs which result in Citrix Mouse Clicks not being recorded by the Citrix Recorder. This issue should be resolved in the ICA Client version 8.1

Important things to consider before replaying a Citrix BDF Script in SilkPerformer. Is the Application being accessed in the Citrix Environment suitable for being access by multiple users? It is important to verify that any application being accessed on the Citrix Server will behave correctly if more than one instance of the application is running. As in a loadtest scenario, multiple virtual users will be interacting with the application. This is fine if a user has only recorded the interaction between a user and note pad however for more complex applications multiple users could be entering data, and printing reports. This could lead to application errors which might invalidate the Citrix test. Therefore it is important to assess whether or not the application can successfully deal with multiple users accessing it at the same time. What happens if applications are changed before a script is replayed? It is therefore vital that windows which are maximized during the record process are maximized during replay. However this is not always the case; for example consider the following: During a Record session a users records the maximizing and minimizing of a Browser Window. A second user then logs in to the Citrix Server and opens a browser window. However, this time he resizes the window by pressing the „Restore Down‟ icon. This will have the affect that any new browser windows launched will now not be launched full screen, it will instead launched in Restore mode. During Try-Script this will cause a replay error as SilkPerformer is expecting all browsers to be maximized when they are launched. You will see the following error: CitrixWaitForWindowCreation(Citrix Engine: 21 - WaitForWindowCreation failed, Window should not be maximized - subsequent operations may fail) It is also important to note that SilkPerformer relies on hash values to verify replayed bitmaps against recorded bitmaps. Hash values are computer-readable values that reflect bitmap specifications such as size, position, resolution, and color depth. Hash values are generated by the Citrix ICA Client. To verify replay screen regions against hash values that are captured during recording it is necessary that the same Windows color depth that is used during recording also be used during replay. Scripts will fail if these specifications are not maintained because changes as small as a single pixel can change hash values and result in replay content appearing to be different from recorded content. Therefore it is of vital that no changes to color or screen positioning are made on the Citrix Server after a script has been recorded and before a script is replayed in SilkPerformer.

Citrix Synchronization and Verification: What is Synchronization? Synchronization can be best described as a group of SilkPerformer BDL functions which ensure that the SilkPerformer runtime engine waits on the Citrix Server to execute certain events. In all cases these are Windows events such as windows creation, windows activation, windows modification and windows deletion. The purpose of the synchronization functions is to ensure the SilkPerformer runtime engine does not execute the next API call until the Citrix Server has returned the associated bitmap for a window. It is important to note that no windows synchronization takes place on the Citrix MetaFrame Server. Synchronization is just a process employed by SilkPerformer to wait until events have been executed. The Synchronization functions are normally followed by user interactions, e.g. CitrixMouseClick, CitrixKeyString etc. There is an important setting which can be configured in SilkPerformer in order to increase the timeout period for which the SP run time engine will wait for a bitmap to be returned by the Citrix Server. By default the setting “Synchronization Timeout” will wait for 60 seconds for the Citrix Server to execute an event; however research has shown that when a Citrix Server is under load conditions that it can often take longer to return the requested bitmaps. Therefore to prevent Timeout Errors occurring during replay for the CitrixWaitForXXX functions a user should increase the timeout value. A typical Time out Error would be: CitrixWaitForWindowCitrixEngine: 22 - WaitForWindow failed, Operation timed out The setting “Synchronization Timeout” can be found in SilkPerformer by going to: SETTINGS | ACTIVE PROFILE | REPLAY | CITRIX | GENERAL

Replay Custom Synchronization functions: CitrixWaitForScreen Screen synchronization can only be added after a Try-Script via the TrueLog Explorer. In order to synchronize screen appearances which are generated from user input in Citrix, a user may need to add this function too stall the SP runtime engine until an expected screen appears. The execution of the script can continue then. CitrixWaitForText In SilkPerformer 7.0 a new synchronization function will be introduced. The function CitrixWaitForText will wait until selected text appears on the screen. This is any text on the screen which can be used by the OCR parsing. Example of when Text Synchronization would be used Imagine a Web Browser rendering HTML content if the page has been updated. In this scenario no windows Synchronization will take place as the browser window stays the same during the process. However, the content of the screen will change. In this scenario a user could make use of the CitrixWaitForText functionality, for example, if it was necessary to wait until a new link appears on a web page. A user can use the TrueLog Explorer in SP 7.0 to customize their script with this new function.

Verification: There are two SilkPerformer Citrix BDL functions used for verification and these are: CitrixVerifyText Uses optical character recognition (OCR) on a selected screen region and compares the result with a provided string. CitrixParseText Uses optical character recognition (OCR) on a selected screen region and stores the result in a variable. After performing verification on text using the TrueLog Explorer Wizard a user will see a function similar to the following generated in the script:
CitrixVerifyText(“Programs”, DESKTOP, 62,343, 62, 32, CITRIX_FLAG_equal, SEVERITY_ERROR, “Arial”, 8, FONT_FLAG_Underlined);

Using this function a user can determine which font, font size and type they need to add to the Citrx OCR settings in SilkPerformer. SETTINGS | SYSTEM | CITRIX

Where can a user perform Verification Consider the BDL code below. I wish to verify the string named “Test”, however this can not be done in the TrueLog Explorer by selecting the API call CitrixKeyString("Test")
CitrixKeyString("Test"); CitrixMouseClick(794, 11, hWnd12, MOUSE_ButtonLeft); //verification can only be performed here on the function below hWnd13 := CitrixWaitForWindowCreation("Microsoft Word", MATCH_Exact, 0x94C801C5, 218, 267, 371, 108);

Verification of text and screens is restricted to CitrixWaitForXXX Functions. The reason why verification can only be performed on synchronization functions is because at user interactions (such as CitrixKeyString) the screen may not be stable. The screen which you have viewed in the TrueLog Explorer may disappear a fraction of a second later. After a synchronization function has been executed it is very likely, that the screen will not change until the next user input or interaction. Therefore it makes sense to perform verification on a stable screen otherwise the verification would fail sporadically.

Frequently Asked Questions Regarding Citrix Support Q) Does SilkPerformer support the testing of a Citrix Server via a firewall? A) The use of a socks proxy is supported for Citrix Communication; therefore a user should implement the function: WebSetProxy(WEB_PROXY_SOCK, "", 80);

Q) What is the recommended number of users when running a loadtest? A) A machine with 1GByte of Memory and 1GByte of CPU available should be able to run approximately 50 virtual users. While a machine with 2GBytes of Memory and 2Gybtes of CPU should be able to run 100 virtual users, please note that the number of virtual users is also dependant on the script actions and the logging options enabled.

Q) Is the caption name the only parameter which is required to confirm if a Windows synchronization function succeed? A) Yes, if the first parameter (windows caption name) is returned by the Citrix Server for a Windows Wait function it will be deemed successful and the other parameters will not be checked. For example consider the following: hWnd13 := CitrixWaitForWindowCreation("Microsoft Word", MATCH_Exact, 0x17CF0000, -4, -4, 808, 580); The additional parameters will only be used for synchronization if the first parameter is omitted from the function or if the window does not have a caption name.

Troubleshooting Citrix Replay Problems in SilkPerformer Using the Virtual User Log Files When troubleshooting a Citrix replay problem or error a user should employ the same methodology that they employ when troubleshooting a Web Application error. Therefore the first port of call should be the “Virtual User” Log files. The virtual user log file which is generated on replay contains information on each users interaction with the Citrix Server, as well as detailed information on how each window behaves. A typical entry in the virtual user log file will look like the following: CitrixMouseClick(MOUSE_ButtonLeft) { Position: 29 / 10 In window: <4> DragX: 0, DragY: 0 Button: MOUSE_ButtonLeft Modifier: MOD_None (A) Window <4> activated (+) Window <11> (65620) created - "" Style: 96400000, ExtStyle: 188 Pos: 2 / 169, Size: 204 x 407 } time: 0.766s, line: 92 This tells you of the position of the screen, the window being used, the position the mouse has been dragged to, the button pressed and if any modifications have been performed on the mouse click during replay. You will also notice lines prefixed with characters such as (A), (+) etc. These characters are used to describe the behavior of a window during the API execution; for example + Windows Construction/Creation - Windows Destroyed A Windows Activation C Windows Caption Change R Windows Resize/Maximize M Windows Move The time: 0.766, includes both the time it took the API call to execute and the time it took the server to return the window bitmap to the client. As the execution time is usually small enough to be discounted, the time returned provides a very true reflection of the time it took the server to send a bitmap to the client for display.

Using the TrueLog Explorer The main purpose of the Citrix TrueLog Explorer is to provide a visual representation of what has occurred during script execution. A user can also customize the script via the TrueLog. As Citrix issues a bitmap for each interaction, the TrueLog is particularly useful for allowing a user to visually verify if the expected screenshot is returned by the server. The principal method of troubleshooting any replay issues is to compare the replayed TrueLog to the recorded TrueLog. A user can of course use the TrueLog Comparison Wizard to compare the Test Run to the Recorded TrueLog. Stepping through the TrueLog a user can then compare the bitmaps returned by the Citrix Server during replay to the bitmaps returned during the record process. These bitmaps can be compared to check for irregularities such as: Change in Window position Change in Window size Change in Color depth Different Window Returned by the Server Changes in color depth are very difficult to identify visually; therefore a user should note before recording the color depth settings on the Citrix Server and then verify the color depth again before replay the BDF script, this can be done by going to: SETTINGS | CONTROL PANERL | DISPLAY PROPERTIES | SETTINGS | COLOR QUALITY The above are some of the most common problems a user can encounter during execution of a Citrix Script in SilkPerformer. Once a user has identified a difference in Window behavior they should access the application via the Citrix Client outside of SilkPerformer and then manually follow the user interaction which is executed in the script to verify if the Window behaves as expected. If the user is also seeing a change in the window behavior when manually accessing the application, for example if a new window is generated by the application then they should consider implementing a fresh record in SilkPerformer. During a load test it is generally not recommended that the settings generate TrueLogs or Virtual User Log files are enabled because of the large memory and CPU overhead that these files can add to a loadtest. However for debugging purposes it is recommended that a user enables TrueLog On Error and also sets SETTINGS | ATCIVE PROFILE | REPLAY | CITRIX | GENERAL | “Log Screen actions before each user action” The above setting will ensure that a bitmap is written to the TrueLog for each synchronization function which is executed thereby helping a user to visually identify if there are problems with the bitmaps returned by the server under load conditions.

Troubleshooting Synchronization: If a user is seeing any errors when executing any of the synchronization functions (CitrixWaitForXXX) the first thing to check is if the user has removed any of the synchronization functions from the script. To do this a user should open the recorded script and compare it to the current script in order to check if any functions have been removed or modified by a user. Dynamic Windows Occasions can arise when a user will manually need to remove certain CitrixWaitForXXX functions from the BDF script. The reason for this is that in some circumstances an application can generate sporadic windows. This will cause the Citrix Replay Engine to go into an error state, because the expected window might not be returned by the Citrix Server. A typical example of this behavior might be a Java Script advertisement window which is occasionally generated when visiting certain home pages. In the case where a window might sporadically appear or disappear it is recommended that a user simply removes the associated function call. Normally these can be safely removed if the user is not performing any interaction on the window. This type of behavior is what is known as an unreliable window and should be avoided when recording and replaying in Citrix where ever possible.

Forcing Window Positions If a newly created or restored window (restored after being minimized) has a different size to the same window which was originally recorded then subsequent user actions on this window will fail. This is because the actions will be performed on an incorrect position on the window. However there is a setting in SilkPerformer which can force the window position on replay of the script to the same position of the window that was recorded during the record process. This will avoid any potential problems where user actions are not executed in the correct place. To enable the setting in SilkPerformer go to: SETTINGS | ATCIVE PROFILE | REPLAY | CITRIX | GENERAL | check „Force Window Position‟. Alternatively the above setting can also be activated in the BDF functions CitrixWaitForWindowCreation and CitrixWaitForWindowRestore By specifying the Boolean value „True‟ for the parameter bForcePos; like so:

hWnd8 := CitrixWaitForWindowCreation("My Documents", MATCH_Exact, 0x16CF0000, 285, 31, 268, 205, True);
Now with the parameter set to True, any newly created windows which return a different size to the size specified by the nWidth and nHeight parameters (size of the window during recording) will be automatically resized.

Running a Citrix BDF script on an Agent or Execution Server Make sure that the same version of the ICA Citrix Client installed on the Agent/Execution Server is installed on the SilkPerformer MMC machine If this is not done the script will fail on the first Citrix function which is CitrixInit. If a user has installed a Citrix client on all agents and execution servers and the Citrix BDF scripts fails even though it can be successfully executed on a SilkPerformer MMC install then this usually indicates connection problems between the Citrix Client and Server. For example in the above scenario if you view the TrueLog On Error you will see the error: CitrixConnectIcaData(CitrixEngine: 6 - Connect failed) If a user encounters the above error then they should first inspect the ICA Data which is sent to the Citrix Server; this can be viewed in the Info tab of the TrueLog Explorer. The data contains a lot of information; however a user should look out for certain key words which might indicate that a third party is involved in the communication between the Citrix client and server. These key words include: ProxyType Username SSLEnable SSLProxyHost In one example where I encountered the above error on a SCPM Execution Server; the root cause of the problem was that the NFuse Citrix Client was communicating with a Proxy Server in order to obtain a client certificate from the Citrix Server. This form of security was to ensure that no Citrix client had direct communication with the Citrix Server to avoid direct attacks or access on the server. The root cause of the problem was that the domain credentials of the Citrix Client used on the SilkPerformer MMC was valid to contact the Proxy Server; the credentials of the SCPM execution Server machine were not. Therefore to workaround the problem the following had to be implemented. On the SCPM Execution Server Click START | CONTROL PANEL | ADMINSITARTIVE TOOLS | SERVICES Select „Segue Execution Server‟ Right click Select „Properties‟ Select „Log On as This Account‟ Enter the User Credentials of the SilkPerformer MMC install before Click Apply.

End Goals and Tuning a Citrix Server What are typical QA Testers end goals? QA Engineers are predominantly looking to test existing applications which are hosted on a Citrix Farm in order to try and verify the scalability of the server. In a lot of test scenarios there will be a single Citrix Server under load conditions so that a QA Engineer can calculate how many users a single Citrix Server can handle. Using this figure they can then calculate the number of Virtual Users a Citrix Farm may be able to handle. distributing the load onto each individual server.

What are the aims of Citrix Testing? Network bandwidth limitation Can the network between the ICA Client and the Server handle the throughput of the traffic under load conditions. Text Timing Issues For example a user would type some text on a screen and then verify using the Citrix Synchronization function to see when the string was displayed on the client. Synchronization on user actions A user would like to time the period of time from when a user completes an action on the client until the associated bitmap is sent to the client. Tuning an application If an application is hosted on a citrix server it is very important to test the application to ensure that the Citrix Server does not have an adverse affect on the performance of the application. Mouse Input Through performance testing a user can adjust how many mouse inputs can be queued before they are sent to the server, this has the effect that it can reduce or increase the network traffic/throughput.

Tuning a Citrix Server Memory is by far the most important hardware component of a Citrix Server. The amount of memory in a server affects the performance of other hardware components. For example, in addition to not being able to support as many users as you‟d like to, not having enough memory can add an extra burden to the processor and disk since the page file would be more heavily used. If you really want to fit more users onto your Citrix server, then a user will need to increase the physical memory. Performance Explorer has a pre-defined monitor/data source named „Terminal Services | Perfmon‟. It is recommend that this monitor is run against the Citrix Server which is being tested with SilkPerformer to help identify any potential bottlenecks or problems; however it is worth noting that there is also additional Perfmon (Performance Monitor) counters which can also be monitored via the SAM feature in order to further help identify any problems on the Citrix Server. Below is a link to an excellent white paper which discusses in detail the best practices to employ in order to get the best out of Citrix MetaFrame Server by performing performance tuning. The white paper also details which additional PerfMon counter should be monitored on a Citrix Server when the Server is under load conditions. (Please note: you will need to complete a form submission before they can download the white paper).

To use the default Citrix monitor in SilkPerformer go to: Performance Explorer | Monitor Server | Predefined Data Sources | Terminal Services | Perfmon Here you will find the following three Perfmon measures for monitoring a Citrix Server: 1) Active Sessions The number of session‟s active on the Citrix Server 2) Inactive Sessions The number of session‟s which although connected to the server are inactive 3) Total Sessions The sum of all inactive and active sessions

List of Citrix Resolutions created by Technical Support Ratings for each resolution in terms of implications of use for troubleshooting *** Indicates Essential Information ** Indicates Useful Information * FAQ * What is the memory consumption when running Citrix tests?
** Why on replay of my Citrix script does the simulation appear to show that text is entered with the CAPSLOCK key pressed in SP 6.6?
** How do I identify the Citrix Client version being used?
*** Why does the CitrixParseText function not return the full result string?
* Will the length of time(s) I specify for the mouse or keyboard key to remain pressed for, be included in the time reported for my custom timers during a Citrix loadtest?
** When running a Citrix script on my agent machine what could cause a timeout to occur after the initial connection?
* When planning to run a citrix loadtest what are the recommendations of the hardware required to support the ICA clients? * How

can the screen resolution at which the SilkPerformer Citrix Recorder will record at be changed?
* How does the licensing for Citrix load testing work? *** When testing Citrix Program Neighborhood 8.0 with SilkPerformer why do mouse
clicks have no effect?
*** Why do I see the Citrix Server error "The system is already being run on this computer but by a different login. You must log the other session off first, before you can run the system again

* What do the coloured borders around windows and the other symbols in Citrix TrueLogs represent?
** What causes the error - CitrixInit CitrixEngine: 43 - Startup failed, Failed to start the core ?
** What causes CitrixConnectIcaData(CitrixEngine: 47 - Invalid parameter)?
* What is the recommended operating system for agents running SilkPerformer Citrix tests?
** Can I monitor a Citrix Server using Performance Explorer?
* Can verification be done on content in a Citrix environment?
* Why do Citrix TrueLog On Error files only show a snapshot of the error screen and no details of other screens in the test?
* What version of Citrix was tested with SilkPerformer 6.5? * What causes the message "The ICA file could not be found" to be displayed during
Citrix recording? * Why does Window Detection in Citrix fail when recording with a previously
disconnected session?
*** Why might I receive CitrixWaitForWindowCreation(Citrix Engine: 21 WaitForWindowCreation failed, Window should not be maximized - subsequent operations may fail) error on replay? ** Why might I receive the error CitrixMouseClick(Citrix Engine: 15 SendMouseDown failed, Position outside the screen)? ** Is it possible to verify the correct screen content is displayed during Citrix replay?

*** Why does my file menu close and generate "CitrixWaitForWindowCreation(CitrixEngine: 36 - The communication failed, Error: 0xe00f0014)" when testing MS Office?

To top