Measures reported by CtxXcXAEuemTest
The figure below depicts a typical user logon process to Citrix XenApp.
The Citrix user logon process
The process depicted by the figure above has been described below:
- User provides his/her credentials to the web interface.
- Web interface forwards the credentials to controller for verification process.
- Delivery controller transfers these credentials to the domain controller to check if the user is present in the active directory.
- Once it gets the successful confirmation from AD then controller communicates with site database to check what type of application is available for current user.
- Controller then interacts with XenApp server to gather information about the availability of virtual desktop.
- Controller then passes the ICA file for user and all the connection information is present inside ICA file so that client can establish the connection.
- After all the process is complete, the user is assigned the application.
- The user then establishes a connection with the assigned application.
- The XenApp server again communicates with controller for verification of licensing.
- Controller checks for license from license server about what type of license is available for user in this current session. License server then communicates back with controller providing the licensing information.
- Information obtained from license server is then passed to the XenApp server.
From the discussion above, it can be inferred that login processing happens at two different places - at the delivery controller, and inside the Citrix XenApp server. While login, authentication, and application brokering happen on the delivery controller, session creation and setup happens inside the XenApp server. A problem in any of these places can result in a poor user experience. Inevitably, these issues result in service desk calls and complaints that “Citrix is slow”. Diagnosing login problems has traditionally been a difficult, time-consuming, manual process due to the large number of steps involved. The key to resolving user experience issues therefore, lies in tracking each user's sessions end-to-end, ascertaining the time spent by the session at each step of the logon process - be it on the delivery controller or on the XenApp server - and accurately identifying where and at what step of the logon process, the slowdown occurred.
To determine the time taken by the entire logon process of a user, isolate logon slowness, and understand where the process was bottlenecked - whether on the delivery controller or on the XenApp server - use the CtxXcXDSUserTest test mapped to the Citrix XA/XD Site component. If the CtxXcXDSUserTest reveals a problem in session start-up on the virtual desktop, then use the CtxXcXAEuemTest test.
With the CtxXcXAEuemTest test, administrators can receive deep visibility into the XenApp end of the Citrix logon process. This test takes an administrator into the XenApp server, reveals the users who are currently logged on to the server, and accurately reports the average time it took for the sessions of each user to start inside the server. This way, administrators can rapidly identify which user's sessions are experiencing undue start-up delays.
In addition, the test also provides a break-up of the session start-up duration. This way, the test precisely pinpoints where the delay occurred - when user credentials were obtained? when credentials were validated? during profile loading? during login script execution? when mapping drives or creating printers?
For this purpose, the test categorizes its metrics into client start-up metrics and server start-up metrics.
The client start-up metrics are concerned with timing the operations that occur from the point when the user requests an application, e.g., by clicking an icon, to the point at which an instance of the ICA client has finished opening a connection to Presentation Server. While connection-brokering mechanisms, such as Web Interface for Citrix® XenApp server or Program Neighborhood® Agent, involve components that are not on the physical client device, the tasks these systems perform have a direct impact on the performance of the connection start-up and are recorded as part of the client-side process.
The server start-up metrics are concerned with timing the operations that occur when creating a new session on the XenApp server. This includes user authentication, client device mapping, profile loading, login scripts execution, and finally, starting the user's application (in the case of a desktop this will be explorer.exe). If a session already exists and a new application is being started through session sharing, only the application start stage will be considered as part of server start-up.
The total time required for these two areas to complete will directly affect the experience of the user while waiting for their application to become ready. This way, the test pinpoints those users whose logins were slow, and also reveals the specific causes of slow logins. This visibility enhances the performance of applications delivered by Citrix XenApp server, resulting in a better user experience.
The measures made by this test are as follows:
| Measurement | Description | Measurement Unit | Interpretation | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| No_of_sessions | Indicates the number of sessons currently open for this user on the XenApp server. | Number | Compare the value of this measure across users to know which user has the maximum number of open sessions. In the event of an overload, this will point you to that user who is contributing the most to the workload of the XenApp server.
Use the detailed diagnosis of this measure to view the complete details of each user session. Such details includes the name and IP address of the client from which every session was launched, when session creation started, and when it ended. With the help of this information, administrators can quickly pinpoint those sessions that may have taken too long to be created. |
||||||||||||
| Logon_duration | Indicates the time taken by this user to complete the logon process. | Secs | Compare the value of this measure across users to know which user took the longest to logon to the XenApp server. To know what is causing this ‘slow login’, compare the values reported by all the other ‘duration’ measures of this test for that user. This will quickly lead you to where that user's logon process is spending the maximum time. | ||||||||||||
| Profile_load_duration | Indicates the time taken to load this user's profile. | Secs | Compare the value of this measure across users to know which user's profile took the longest to load. If that user's Logon duration is high, you may want to compare the value of this measure with that of the other ‘duration’ measures reported for this user to figure out if a delay in profile loading is what is really ailing that user's logon experience. One of the common reasons for high profile load time is the large size of the user profile. Use the User Profile test to know if this user's profile is indeed exceeding the configured size limit. If so, use the UserProfileTest test again to know which specific files in that user's profile are contributing to its large size, and check if such files can be deleted to reduce profile size, and consequently, the logon duration. Moreover, this measure reports the average time taken for loading a user's profile across all the sessions of that user. To know the profile load time per user session, use the detailed diagnosis of this measure. This will accurately pinpoint the session in which the profile took the longest to load. |
||||||||||||
| GP_duration | Indicates the time taken by this user's session to process group policies. | Secs | Compare the value of this measure across users to know which user's sessions took the longest time to process group policies. If that user's Logon_duration is high, you may want to compare the value of this measure with that of the other ‘duration’ measures reported for this user to figure out if a delay in group policy processing is what is really ailing that user's logon experience. Logon performance improves when fewer Group Policies are applied. Merge GPOs when possible instead of having multiple GPOs. |
||||||||||||
| Login_script_duration | Indicates the time taken for the login script to execute for this user. | Secs | Compare the value of this measure across users to know for which user the login script took the longest time to execute. If this user complains of slowness, then, you can compare the value of this measure with that of the other ‘duration’ measures of that user to figure out what could have really caused the slowness. |
||||||||||||
| C_startup | This is the high-level client-side connection start-up metric. It starts at the time of the request (mouse click) and ends when the ICA connection between this user's client device and XenApp server has been established. | Secs | In the case of a shared session, this duration will normally be much shorter, as many of the set-up costs associated with the creation of a new connection to the server are not incurred. When any user complains of slowness, you may want to compare the value of this measure with that of the S_session_startup measure of that user to know whether a client-side issue or a server-side issue is responsible for the slowness. If this comparison reveals that the C_startup of the user is high, it indicates a client-side issue that is causing long start times. In this case therefore, compare the value of the client start-up metrics such as the C_app_enum, C_config_file_download, C_cred_obtention, C_ica_file_download, C_launch_page_web_server, C_name_resolution, C_name_resolution_ws, C_session_lookup, C_session_creation, and C_ticket_res_ws to know what client-side issue is causing the C_startup to be high. |
||||||||||||
| C_backup_url_count | This measure is relevant when the XenApp plugin is the application launch mechanism. It records the number of back-up URL retries before a successful launch. Note that this is the only start-up metric that is a measure of attempts, rather than time duration. | Number | If this metric has a value higher than 1, it indicates that the Web Interface server is unavailable and the XenApp Plugin (formerly known as Program Neighborhood Agent) is attempting to connect to back-up Web Interface servers to launch the application. A value of 2 means that the main Web Interface server was unavailable, but the XenApp Plugin managed to the launch the application successfully using the first back-up server that it tried. A value higher than 2 means that multiple Web Interface servers are unavailable. Probable reasons for the non-availability of the Web Interface servers include (in order of likelihood):
|
||||||||||||
| C_app_enum | This measure is relevant when the XenApp plugin is the application launch mechanism. It measures the time needed by this user's sessions to retrieve the list of applications from the Web Interface service. | Secs | If the C_startup measure reports a high value for a user, then compare the value of this measure with that of the other client-side metrics such as C_config_file_download, C_cred_obtention, C_ica_file_download, C_launch_page_web_server, C_name_resolution, C_name_resolution_ws, C_session_lookup, C_session_creation, and C_ticket_res_ws to know whether/not slowness in application enumeration is the precise reason why it took the user a long time to establish an ICA session with the XenApp server. | ||||||||||||
| C_config_file_download | This measure is relevant when the XenApp plugin is the application launch mechanism. It measures the time this user's sessions took to retrieve the configuration file from the XML server. | Secs | If the C_startup measure reports a high value for a user, then compare the value of this measure with that of the other client-side metrics such as C_app_enum, C_cred_obtention, C_ica_file_download, C_launch_page_web_server, C_name_resolution, C_name_resolution_ws, C_session_lookup, C_session_creation, and C_ticket_res_ws to know whether/not slowness in retrieving the configuration file from the XML server is the precise reason why it took the user a long time an ICA session with the XenApp server. | ||||||||||||
| C_cred_obtention | This measure is relevant when the XenApp plugin is the application launch mechanism. It measures the time required by this user's sessions to obtain the user credentials. | Note that COCD is only measured when the credentials are entered manually by the user. Because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it is subtracted from the C_startup. However, in the event that the user manually inputs the credentials, and the value of this measure is higher than that of all the other client start-up metrics that this test reports, it is a clear indicator that any connection delay that the user may have experienced is owing to slowness in obtaining user credentials. |
|||||||||||||
| C_ica_file_download | This measure is relevant when the XenApp plugin or Web Interface is the application launch mechanism. This is the time it takes for this user's client to download the ICA file from the web server. | Secs | The overall process here is:
This measure represents the time it takes for the complete process (step 1 to 6). The measure stops counting time when the client receives the ICA file data. |
||||||||||||
| C_launch_page_web_server | This measure is relevant when the Web Interface is the application launch mechanism. It measures the time needed by this user's sessions to process the launch page (launch. aspx) on the Web Interface server. | Secs | If the value of this measure is high, it indicates at a bottleneck on the Web Interface server.
Possible causes include:
|
||||||||||||
| C_name_resolution | This is the time it takes the XML service to resolve the name of a published application to an IP address. | Secs | This metric is collected when a client device directly queries the XML Broker to retrieve published application information stored in IMA (for example, when using the XenApp Plugin or a Custom ICA Connection). This measure is only gathered for new sessions since session sharing occurs during startup if a session already exists.
When this metric is high, it indicates the XML Broker is taking a lot of time to resolve the name of a published application to an IP address. Possible causes include a problem on the client, issues with the XML Broker, such as the XML Broker being overloaded, a problem with the network link between the two, or a problem in IMA. Begin by evaluating traffic on the network and the XML Broker. |
||||||||||||
| C_name_resolution_ws | This measure is relevant when the XenApp plugin or Web Interface is the application launch mechanism. It is the time it takes the XML service to resolve the name of a published application to a XenApp Server address | Secs | When this metric is high, there could be an issue with the Web Interface server or the XenApp plugin site (formerly known as the Neighborhood Agent site), the XML Service, the network link between the two, or a problem in IMA.
Like the C_name_resolution measure, this metric indicates how long it takes the XML service to resolve the name of a published application to a XenApp IP address. However, this metric is collected when a Web Interface site is performing this process on behalf of a launch request it has received from either the XenApp plugin (previously known as Program Neighborhood Agent) or from a user clicking a Web Interface page icon. This metric applies to all sessions launched through the Web Interface or the XenApp plugin (formerly, the Program Neighborhood Agent). |
||||||||||||
| C_session_lookup | Indicates the time this user's sessions take to query every ICA session to host the requested published application. | Secs | The check is performed on the client to determine whether the application launch request can be handled by an existing session. A different method is used depending on whether the session is new or shared. | ||||||||||||
| C_session_creation | Indicates the new session creation time, from the moment wfica32.exe is launched to the establishment of the connection. | Secs | In the event of slowness, if the C_startup of a user session is found to be higher than the S_session_startup, you may want to compare the value of this measure with all other client start-up measures to determine whether/not session creation is the process that is slowing down the application launch. | ||||||||||||
| C_ticket_res_ws | This measure is relevant when the XenApp plugin or Web Interface is the application launch mechanism. This is the time this user’s sessions take to get a ticket (if required) from the STA server or XML service. | Secs | When this metric is high, it can indicate that the Secure Ticket Authority (STA) server or the XML Broker are overloaded. | ||||||||||||
| C_reconnect_enum | This measure is relevant when the XenApp plugin is the application launch mechanism. This is the time it takes this user's client to get a list of reconnections. | Secs | Compare the value of this measure with that of other client start-up metrics for a user to know what is the actual cause for the client start-up delay. | ||||||||||||
| C_reconnect_enum_ws | This measure is relevant when the XenApp plugin or Web Interface is the application launch mechanism. This is the time it takes the Web Interface to get the list of reconnections for this user from the XML service. | Secs | Compare the value of this measure with that of other client start-up metrics for a user to know what is the actual cause for the client start-up delay. | ||||||||||||
| S_session_startup | This is the high-level server-side connection start-up metric. It includes the time spent on the XenApp server to perform the entire start-up operation. | Secs | In the event of an application starting in a shared session, this metric is normally much smaller than when starting a completely new session, which involves potentially high- cost tasks such as profile loading and login script execution.
When this metric is high, it indicates that there is a server-side issue increasing session start times. To zero-in on this issue, compare the values of the server start-up metrics such as S_session_creation, S_cred_obt, S_PNC_obt, S_cred_obt_network, S_cred_auth, S_profile_load, S_login_script_exe, S_drive_mapping, and S_printer_creation. |
||||||||||||
| S_session_creation | Indicates the time spent by the server in creating the session for this user. | Secs | This duration starts when the ICA client connection has been opened and ends when authentication begins. This should not be confused with ‘Session start-up server duration’. | ||||||||||||
| S_cred_obt | Indicates the time taken by the server to obtain the credentials of this user. | Secs | This time is only likely to be a significant if manual login is being used and the server-side credentials dialog is displayed (or if a legal notice is displayed before login commences). Because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it is not included in the S_session_startup.
However, in the event that the user manually inputs the credentials, and the value of this measure is higher than that of all the other client start-up metrics that this test reports, it is a clear indicator that any connection delay that the user may have experienced is owing to slowness in obtaining user credentials. |
||||||||||||
| S_cred_obt_network | Indicates the time spent by the server performing network operations to obtain credentials for this user. | Secs | This only applies to a Security Support Provider Interface login (a form of pass-through authentication where the client device is a member of the same domain as the server and Kerberos tickets are passed in place of manually entered credentials). | ||||||||||||
| S_PNC_obt | Indicates the time needed for the server to cause the Program Neighborhood instance running on the client (“Program Neighborhood Classic”) to obtain this user's credentials. | Secs | As in the case of the S_cred_obt duration metric, because this metric may be artificially inflated if a user fails to provide credentials in a timely manner, it is not included in the S_session_startup. | ||||||||||||
| S_cred_auth | Indicates the time spent by the server when authenticating the user's credentials against the authentication provider, which may be Kerberos, Active Directory® or a Security Support Provider Interface (SSPI). | Secs | Where server-side issues are causing user experience to deteriorate, you can compare the value of this measure with that of all the other server start-up metrics that this test reports - i.e., S_session_creation, S_cred_obt, S_PNC_obt, S_cred_obt_network, S_profile_load, S_login_script_exec, S_drive_mapping, and S_printer_creation - to know what is the root-cause of delays in server start-up. | ||||||||||||
| S_profile_load | Indicates the time required by the server to load this user's profile. | Secs | If this metric is high, consider your Terminal Services profile configuration. Citrix Consulting has found that when customers have logon times greater than 20 seconds, in most cases, this can be attributed to poor profile and policy design. Roaming profile size and location contribute to slow session starts. When a user logs onto a session where Terminal Services roaming profiles and home folders are enabled, the roaming profile contents and access to that folder are mapped during logon, which takes additional resources. In some cases, this can consume significant amounts of the CPU usage.
Consider using the Terminal Services home folders with redirected personal folders to mitigate this problem. In general, consider using Citrix Profile management to manage user profiles in Citrix environments. This tool also provides logging capabilities to help isolate profile issues. If you are using Citrix profile management and have slow logon times, check to see if your antivirus software is blocking the Citrix profile management tool. |
||||||||||||
| S_login_script_exec | Indicates the time needed by the server to run this user's login script(s). | Secs | If the value of this measure is abnormally high for any user, consider if you can streamline this user or group's login scripts. Also, consider if you can optimize any application compatibility scripts or use environment variables instead. | ||||||||||||
| S_drive_mapping | Indicates the time needed for the server to map this user's client drives, devices and ports. | Secs | Make sure that, when possible, your base policies include settings to disable unused virtual channels, such as audio or COM port mapping, to optimize the ICA protocol and improve overall session performance. | ||||||||||||
| S_printer_creation | Indicates the time required for the server to synchronously map this user's client printers. | Secs | If the configuration is set such that printer creation is performed asynchronously, no value is recorded for this measure as it is does not impact completion of the session start-up.
On the other hand, if excessive time is spent mapping printers, it is often the result of the printer autocreation policy settings. The number of printers added locally on the users' client devices and your printing configuration can directly affect your session start times. When a session starts, XenApp has to create every locally mapped printer on the client device. Consider reconfiguring your printing policies to reduce the number of printers that get created - especially if users have a lot of local printers. |
||||||||||||
| Profile_provider | Indicates the provider who handles this user's profile. | The values reported by this measure and their corresponding numeric equivalents are described in the table below:
Note: By default, this measure reports the above-mentioned Measure Values while indicating the provider who handles this user's profile. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 0 to 2. |
|||||||||||||
| Profile_type | Indicates the type of this user's profile. | The values reported by this measure and their corresponding numeric equivalents are described in the table below:
Note: By default, this measure reports the above-mentioned Measure Values while indicating the profile type of this users. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 0 to 4. |
|||||||||||||
| GP_policy | Indicates the current status of the Group policy that is applied for this user. | The values reported by this measure and their corresponding numeric equivalents are described in the table below:
Note: By default, this measure reports the above-mentioned Measure Values while indicating the current status of the Group policy. However, in the graph of this measure, the values will be represented using the corresponding numeric equivalents i.e., 1to 3. |
|||||||||||||
| User_accnt_discvry | Indicates the amount of time taken by the system call to get account information for this user during the last measurement period. | Secs | Compare the value of this measure across users to know which user's logon process spent maximum time in retrieving account information. To know which domain controller and DNS is being used, use the detailed diagnosis of this measure. |
||||||||||||
| LDAP_discvry | Indicates the amount of time taken by the LDAP call for this user to connect and bind to Active Directory during the last measurement period. | Secs | Compare the value of this measure across users to know which user's logon process spent maximum time in connecting to Active Directory. Besides impacting authentication time, high LDAP bind time may also affect group policy processing. | ||||||||||||
| DC_discvry | Indicates the time taken to discover the domain controller to be used for processing group policies for this user during the last measurement period. | Secs | Compare the value of this measure across users to know which user's logon process spent maximum time in domain controller discovery. | ||||||||||||
| Tot_GP_accesstime | Indicates the amount of time the logon process took to access group policy object files for this user during the last measurement period. | Secs | Compare the value of this measure across users to know which user's logon process spent maximum time in accessing the group policy object file. To know which files were accessed and the time taken to access each file, use the detailed diagnosis of this measure. With the help of the detailed diagnostics, you can accurately isolate the object file that took the longest to access, and thus delayed the logon process. |
||||||||||||
| CSE_apply | Indicates the total number of client side extensions used for processing group policies for this user during the last measurement period. | Number | |||||||||||||
| CSE_success | Indicates the number of client side extensions that were successfully used for processing group policies for this user during the last measurement period. | Number | Use the detailed diagnosis of this measure to know which were the successful client side extensions for a user, and which group policy was processed by each extension. | ||||||||||||
| CSE_warn | Indicates the number of warnings received when client side extensions were used for processing group policies for this user during the last measurement period. | Number | Use the detailed diagnosis of this measure to know which were the client side extensions that resulted in the generation of warning events at the time of processing. You will also know which group policies were processed by each extension. | ||||||||||||
| CSE_error | Indicates the number of errors registered when client side extensions were used for processing group policies for this user during the last measurement period. | Number | Ideally, the value of this measure should be zero. A sudden/gradual increase in the value of this measure is a cause of concern. If a non-zero value is reported for this measure, then use the detailed diagnosis of this measure to know which client side extensions resulted in processing errors. You will also know which group policies were processed by each such extension. Moreover, the error code will also be displayed as part of detailed diagnostics, so that you can figure out what type of error occurred when processing the client side extensions. |
||||||||||||
| CSE_processtime | Indicates the amount of time that client side extensions took for processing group policies for this user during the last measurement period. | Secs | Compare the value of this measure across users to know which user's logon process spent maximum time in client side extension processing. If this measure reports an unusually high value for any user, then, you may want to check the value of the LDAP_discvry measure for that user to figure out if a delay in connecting to AD is affecting group policy processing. This is because, group policies are built on top of AD, and hence rely on the directory service's infrastructure for their operation. As a consequence, DNS and AD issues may affect Group Policies severely. One could say that if an AD issue does not interfere with authentication, at the very least it will hamper group policy processing. You can also use the detailed diagnosis of this measure to know which client side extension was used to process which group policy for a particular user. Detailed diagnostics also reveal the processing time for each client side extension. This way, you can quickly identify the client side extension that took too long to be processed and thus delayed the user logon. |
||||||||||||
| Net_bandwidth | Indicates the estimated network bandwidth between the VM and domain controller for this user during the last measurement period. | Kbps | |||||||||||||
| Is_slow_link | Indicates whether/not the network connection between the VM and domain controller is currently slow for this user. | Several components of Group Policy rely on a fast network connection. If a fast connection is unavailable between a VM and the DOC, group policy processing can be delayed. This is why, if the GP_time measure reports an abnormally high value, you may want to check the value of the Is_slow_link measure to determine whether the network connection between the VM and domain controller is slow. If the network connection between the VM and domain controller is slow for a user, then this measure will report the value Yes. If it is fast, then this measure will report the value No (connection is fast). The numeric values that correspond to the above-mentioned measure values are as follows:
Note:
|
|||||||||||||
| Background_process | Indicates whether the group policy for this user is applied during foreground processing or background processing. | Foreground and background processing are key concepts in Group Policy. Foreground processing only occurs when the machine starts up or when the user logs on. Some policy areas (also called Client Side Extensions (CSEs)) can only run during foreground processing. Examples of these include Folder Redirection, Software Installation and Group Policy Preferences Drive Mapping. In contrast, background processing is that thing that occurs every 90 or so minutes on Windows workstations, where GP refreshes itself periodically. Background processing happens in the background, while the user is working and they generally never notice it. While background processing does not impact performance, foreground processing can extend start and login times. The values that this measure can report and their corresponding numeric values are listed in the table below:
Note: By default, this test reports the Measure Values listed in the table above to indicate when the group policy of a user was applied. In the graph of this measure however, the same is indicated using the numeric equivalents only. |
|||||||||||||
| Sync_process | Indicates whether the group policies of this user are processed in the synchronous or asynchronous mode. | Foreground processing can operate under two different modes - synchronously or asynchronously. Asynchronous GP processing does not prevent the user from using their desktop while GP processing completes. For example, when the computer is starting up, GP asynchronous processing starts to occur for the computer, and in the meantime, the user is presented the Windows logon prompt. Likewise, for asynchronous user processing, the user logs on and is presented with their desktop while GP finishes processing. The user is not delayed getting either their logon prompt or their desktop during asynchronous GP processing. When foreground processing is synchronous, the user is not presented with the logon prompt until computer GP processing has completed after a system boot. Likewise the user will not see their desktop at logon until user GP processing completes. This can have the effect of making the user feel like the system is running slow. In short, synchronous processing can impact startup time, where asynchronous does not. Foreground processing will run synchronously for two reasons:
The values that this measure can report and their corresponding numeric values are listed in the table below:
Note: By default, this test reports the Measure Values listed in the table above to indicate when the group policy of a user was applied. In the graph of this measure however, the same is indicated using the numeric equivalents only. |
|||||||||||||
| Is_profile_quota_exceeded | Indicates whether the profile size of this user exceeds the default profile quota size of 100MB. | Boolean | If this measure shows 0, it indicates that the current profile size has not exceeded the quota size. The value 1 indicates that the current profile size has exceeded the quota size. | ||||||||||||
| Current_profile_size | Indicates the current profile size of this user. | MB | |||||||||||||
| Num_files_in_profile | Indicates the number of files available in this user profile. | Number | |||||||||||||
| Num_large_files | The number of files in this user profile, which exceed the default file size limit of 100 MB. | Number | The detailed diagnosis of this measure, if enabled, lists all the files that have exceeded the default file size limit of 100 MB. |