Hello AskPerf! My name is Prachi Singh and today I will be talking about a behavior that can occur when users attempt to pull licenses from a 2012 R2 License server via a 2008 R2 Session Host. Under these circumstances, you may see a line item in your 2012 R2 license manager that says “Windows Server 2008 or Windows Server 2008 R2 -Installed TS or RDS Per User CAL”. Under “License Program” you then see “Built-in Overused”.

In the case above, the license server is used to issue RDS CALs to users when they connect to both Windows Server 2008 R2 and Windows Server 2012 R2 Session Host Servers. When a user connects to a Windows Server 2012 R2 Session Host, a Windows Server 2012 "per User" RDS CAL is issued.

However, when a user connects to a Windows Server 2008 R2 RDS Server, a Windows Server 2008 R2 "Built-in OverUsed" RDS CAL category appears and shows the value only for the issued RDS CAL. The "Total" and "Available" values remain 0. Additionally, the issued RDS CAL amount is not deducted from the total Windows Server 2012 RDS CALs.

What is the "Built-in OverUsed" group and is it ok to have it?

The "Built-In Overused" group was also used in earlier operating systems if the licensing mode was being set to Per User but no "per user" CALs were installed on the license server and the users will still connect to the terminal servers. This was an indication for admins that they must install licenses. After the applicable licenses get installed, this group goes away and the number of licenses issued gets synchronized with the installed license group.

Why are Windows Server 2008 R2 RDS CALs not deducted from the installed Windows Server 2012 RDS CALs?

By default, a license server attempts to provide the most appropriate RDS CAL for a connection. For example, a license server running Windows Server 2008 R2 tries to issue a Windows Server 2008 R2 RDS CAL for clients connecting to an RD Session Host server running Windows Server 2008 R2, and a Windows Server 2003 TS CAL for clients connecting to a terminal server running Windows Server 2003. If the most appropriate RDS CAL is not available, a license server running Windows Server 2008 R2 issues a Windows Server 2008 R2 RDS CAL, if available, to a client connecting to a terminal server running Windows Server 2003 or Windows Server 2000.

Why are the "Built-In Overused" RDS CALs “issued” counted but not the “total” and “remaining” too?

Starting with Windows Server 2012 R2 license server, when only Windows Server 2012 RDS CALs are installed and a user logs on to a Windows Server 2008 R2 RDS Server, the "Built-in OverUsed" group is displayed and the user gets a 2008 R2 "Built-In Overused" RDS CAL. Here, in this case it is just a reporting mechanism to tell that these number of users have logged in without an appropriate CAL. This is to make admins visible that 2012 licenses were issued for older terminal servers for which no dedicated (in this case the 2008 R2) RDS CALs are installed.

Since, this group is displayed separately, the number of licenses will not be deducted directly from the 2012 RDS CAL group. The "Built-In Overused" group will display only the number of licenses issued and no " Remaining" or "total", because in the background the 2008 RDS CALs are not actually installed. The column “Built-in Overused” represents the number of user connections to Windows Server 2008 R2 servers where a Per User license was issued.

Do you need to install additional Windows Server 2008 R2 RDS CALs too, or is this a compatibility behavior?

Server 2012 RDS requires a Server 2012 RD Licensing server.  A 2012 RD Licensing server will serve 2012/2008 R2/2008/2003 servers, so you may consolidate your RDS CALs onto a Server 2012 RD Licensing server if you would like to.

RDS CALs are not forward compatible, only backward compatible. Meaning that Windows Server 2012 CALs will work with Server 2008 R2

Windows Server 2012 RDS CALs can be issued to 2003, 2008/R2 terminal server. For more detailed info, you may check below article:

RDS and TS CAL Interoperability Matrix

The above screenshot shows that there are 4 users who are connecting to 2008 R2 Session Host Server and 1 user who connects to 2012 R2. With respect to reporting, the admin has the number of issued RDS CALs (Built-in OverUsed + 2012 RDS CALs) and they should make sure that the total does not exceed the number of installed RDS CALs.

The RDS CAL reports will contain information about both (Built-in Overused + 2012 RDS CALs)

Are the "Built-In Overused" RDS CALs handled like any other CALs, especially regarding license renewal?

Per user "RDS CALs are valid 60 days but can be extended automatically if the user logs on again to the RDS server. If the license it has is within seven days of expiring, then the RD Session Host server attempts to obtain a license for the User at each login. If the server cannot find a license server to renew the license before it expires or no license is available, the license will expire. If the server has the licenses available, it will issue it to the user. This is how a "Built-in OverUsed" per user CALs as well as all other "normal" per user RDS CALs behaves.

When a user (which got "Built-In Overused" RDS CAL issued) logs on to a Windows Server 2012 R2 RDS server, the built-in overused CAL gets converted to 2012 RDS CAL. Once converted, the user will continue using 2012 RDS CAL even if he connects to 2008 R2 RDS server ( once "upgraded" the license is no longer "downgraded").

The report will look something like this:

-Prachi

Hello AskPerf! Ishu Sharma here again from Microsoft Performance team.  Today I will be discussing an issue where multiple per device Remote Desktop Services CALS are issued to the same device.
Before we dive into this topic, I would like to recall the below facts about RDS Per Device Licensing.

If an unlicensed client connects to a Remote Desktop Server for the first time, the Remote Desktop Licensing Server issues the client a temporary RDS Client Access License (CAL). After the user has logged into the session, the RDS server instructs the License Server to mark the issued temporary RDS CAL token as being validated. The next time the client connects, an attempt is made to upgrade the validated temporary RDS CAL token to a full RDS CAL token. If no license tokens are available, the temporary RDS CAL token will continue to function for 90 days.
When a client device receives an RDS Device CAL from an RDS Host, it receives it in the form of a digital certificate from a license server. That certificate is saved in the below location on Licensing server:

[HKLM\Software\Microsoft\TermServLicensing\Certificates]
[HKLM\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.000]
[HKLM\System\CurrentControlSet\services\TermservLicensing\Parameters\Certificates.001]

The digital certificate is an actual certificate copied to the client device. Once a client device connects to an RDS Host, an RDS CAL digital certificate is transferred from the license server to the client device. The license server loses one of its licenses from its inventory, and the client device has the digital certificate that it can present to any RDS Host on future connections.

Clients store their license under the key:

[HKEY_LOCAL_MACHINE\Software\Microsoft\MSLicensing]

The MSLicensing key contains two sub-keys used to store both unique client-specific information and any license certificates obtained from license servers.

HardwareID
Store

HardwareID stores a Random 20-byte identifier specific to the client machine and is generated automatically by Windows. This ID uniquely identifies the machine to the license server. When a client is allocated an RDS CAL from the license server, this HardwareID is recorded in the licensing database to associate the client with the CAL. This entry is made when clients are allocated both temporary CALs and permanent licenses.

Store is used to store the terminal services CAL allocated from the license server.  Entries are contained in sub key named License00x, where X is a numerical ID beginning with 0.  Each License00x entry contains a separate CAL.

The License00x entry contains four binary components that comprise a terminal services CAL certificate:

• ClientLicense
• CompanyName
• LicenseScope
• ProductID

Every time the client device connects to an RDS Host, it presents its RDS CAL certificate to the server. The server checks not only whether the client device has a valid certificate, but also the expiration date of that certificate. If the expiration date of the certificate is within 7 days of the current date, the RDS Host connects to the license server to renew the license for another random period of 52 to 89 days.

Ideally each Client device should be issued only one RDS CAL. However, there would be times where License Server Manager will show multiple per device CALS being issues to the same device as shown in the below picture:

Now this is intriguing!! Why is the same device consuming multiple RDS CALS? The administrators usually notice this issue when they start running out of per device CALS and when they check the list of issued per device CALS in RDS licensing Manager, they notice that multiple RDS CALS have been issues to the same device.
To temporarily get around this issue you can revoke licenses but the catch is that you can only revoke 20% of the CALS at one time. This may not help if you have very few CALS left and you see that multiple per device CALS are being allocated to multiple machines.

Below are the possible reasons which can cause this issue:

1.    If you have built multiple machines using the same image:

a)    There could be times when you used a syspreped image or Citrix provisioned machines where the HardwareID was defined in the image because of which each device which was built using that image got the same hardware ID. This would result in the below situation:

• If Client1 has HWID xxxx and logs into the RDS, it will get license 1
• Then Client 2 which also has HWID xxx logs in and does not have license 1, so it's issued a new license, license 2
• If Server 1 tries to log in again, the xxx HWID is now associated with license 2, which Client 1 does not have, so Client 1 will get issued a new license, license 3
• Now the XXX HWID is associated with license 3
• Every time that HWID logs in, no matter what machine it is, its license will be compared to what's in the database for HWID XXX
• That's where the problem comes in — machines are constantly getting new licenses, even when they aren't needed.

Resolution In order to get around this issue, you need to rectify the image itself and use a syspreped image which does not have MSLicensing Key information of the original machine hardcoded to it

b)    You Create a Citrix Provisioned machine where all the machines are booted from a pre-defined image and all the changes are lost after reboot. So every time the machine connects it gets a new ClientHWID and this is lost on the next boot. The next time the machine connects to the RDS Host, it gets a new Client HWID and hence a new RDS license is issued. Citrix XenDesktop provisioned machine with different hardware ID which can cause the license server to recognize it as different device and issue duplicate licenses

Resolution It is recommended to use Per-User RDS licensing in these scenarios, because the licenses are reverted when the user logs off, hence the number of licenses will not be affected.

2.    This could also happen if you have a script in place which deletes MSLicensing Key at shutdown.

Resolution Remove the script

3.    Different machines using same name.

If machines are cloned, sometimes third party cloning tools do not wipe out all the stale information and the cloned clients although with a different hardware it would give the same computer name to the RDS Host.

Though the Hardware ID might be different, if two different machines have the same name, looking at the Licensing Manager you might think that the same device is using multiple CALS but it is not.

4.    Machine was re-built:

For some reason if a machine that got a CAL once is re-built then due the new installation it got a new hardware ID and when connected again to Remote desktop server and hence got another CAL.

Assume that a client device successfully authenticates to an RDS Host and is granted a full RDS CAL certificate that was (worst case) randomly selected to expire at the 89 day maximum. When it passes down the certificate, the license server decrements its total RDS CAL license count by one, also noting that particular certificate's expiration date. Now, assume that a catastrophic event occurs at the client, causing its local operating system to be reinstalled and its local RDS CAL certificate to be lost. When that client authenticates to an RDS Host, the RDS will request a new RDS CAL certificate from the license server and the license server (again) decrements its RDS CAL inventory by one. At this point there have been two RDS CAL licenses given out to that one client, but the first one will never be renewed because the certificate was lost when the client was rebuilt. After 89 days (the randomly selected duration of the first certificate), the first RDS CAL is returned to the pool by the license server.

Resolution The old CAL will be freed within next 52-89 days after being issued or you can simply revoke the old CAL.

5.     Multiple Hardware ID’s in the MSLICENSING Reg key of the client machine:

This could happen if the license has been corrupted. If it has already been corrupted, a new hardware ID will be generated automatically for the client during next RDS Host logon and hence you may notice duplicate CALS for that device.

Resolution To determine which one you need to delete, go to the server, and open PowerShell “As Administrator” on the RDS License server, and execute the following command: get-wmiobject Win32_TSIssuedLicense | export-csv [outputfile]
Then in the output file, find out the client who is issued with multiple licenses, then record the hardware ID within the license which is not the most recently issued.
Then go back to the client, open registry, locate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID and check the ClientHWID which matches the one you just record, delete the HardwareID subkey.

DATA collection

1.    Look at TerminalServices-Licensing event logs.
2.    Generate per device RDS Per device Cal report to verify if the issue is because of multiple Hardware ID’s issued to the same machine, or same hardware ID issued to different machines or due to duplicate Machine names with different Hardware IDs.

Script for RDS Per Devices CALs (PowerShell)

This shows Keypack ID, License ID, Name of the client device along with Hardware ID and Expiration date of the CAL as shown below.

3. Use the RDS Client License Test tool (TSCTST.EXE) provided with the Windows Server 2003 Resource Kit on the client machine for which you see multiple CALS to display details about the license token residing on a client device. It is a command-line utility that displays the following information by default:

• Issuer
• Scope
• Issued to computer
• Issued to user
• License ID
• Type/Version
• Valid From
• Expires On

By using the /A switch, the following additional information is displayed:

• Server certificate version
• Licensed product version
• Hardware ID
• Client platform ID
• Company name

3. If you are still not able to find the cause, Microsoft professional can help you collect an RDS Licensing ETL trace while reproducing the issue. The etl trace should tell what name / HWID was used to request new licenses.

Quick Workarounds

1.    If all per device CALS are exhausted and you are working to find the case of multiple RDS CALS being issued to same device, temporarily you can change the licensing mode to per user to allow remote sessions. However, this should not be a practice as it will be a breach of Microsoft Licensing agreement.

2.    Regenerate the ClientHWID and Rebuild the License server database (KB273566) and reinstall the CAL Packs to restore all the CALS.

The hardware ID can be regenerated by deleting the below keys manually:

Reg Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID

Reg Delete HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store /f

The next time you need to take an Remote session as an admin to regenerate the hardware ID as normal users do not have permissions on this registry key. Or you can use tools (RegenerateHDWID) to regenerate the hardware ID’s on the fly.

-Ishu

Hello AskPerf blog readers! Jeff here from the Windows Performance Team once again. I am happy to announce that the new version of WMIDIAG is finally here. It’s now compatible for Windows 8/8.1 as well as Sever 2012/2012R2. Some of you may have been aware that the previous version used to also show a lot of errors and that majority of them were erroneous or false positives simply due to wmi class name changes between OS versions. That has been all cleaned up and all errors have been corrected. When you run the new version it should look a lot cleaner and what errors you do see should be accurate and deserving of attention.

The WMI Diagnosis Tool is a VBScript based-tool for testing, validating, and analyzing WMI installation/issues. The tool collects data from WMI installations on all Microsoft Operating Systems at any or no service pack level.

WMI Diagnostics 2.2 requires you to have Local Administrator rights as well as Windows Script Host (WSH) enabled.

To download this tool, please click here.

After you download WMIDiag.exe, run it and extract the files to a local folder. If you double-click WMIDiag.vbs, the following message will appear:

If you want to see its activity, then you would run “cscript WMIDiag.vbs” from the command prompt, or you can change the default script host to the command line by running “cscript //H:CScript”.

Note: By default WMIDiag does not check repository consistency and you would need to run manually from command prompt using “cscript WMIDiag.vbs checkconsistency”

WMIDIAG can be run from Windows Explorer, or from the command line. Each time it runs, the WMI Diagnosis Tool creates the following three files in the %TEMP% directory:

• .LOG file containing all the WMI Diagnosis Tool activity as well as a WMI report at the end
• .TXT file containing the WMI Diagnosis Tool report
• .CSV file containing statistics that can be used to measure trends and issues

When the WMI Diagnosis Tool terminates, the ERRORLEVEL environment variable is set to one of the following values:

0 = SUCCESS

• WSH has a script execution timeout setup (in machine or system environment)
• Machine reports suspicious improper shutdowns
• User Account Control (UAC) status is reported (Vista and above)
• Local account token filter policy is reported (Vista and above)
• Unexpected binaries in the WBEM folder
• The Windows Firewall is enabled
• Some WMI service installed in the machine are dependent on the WMI service (i.e. "SMS Agent)
• WMI ADAP has a status different than 'running'
• Some WMI namespaces require a packet privacy encryption for a successful connection
• Some WMI permanent subscriptions or timer instructions are configured
• Some information about registry key configurations for DCOM and/or WMI was reported

1 = ERROR

• System32 or WBEM folders are not in the PATH
• WMI system file(s)\ repository is/are missing
• WMI repository is inconsistent (XP SP2, 2003 SP1 and above)
• DCOM is disabled
• WMI service is disabled
• The RPCSS and/or the WMI service(s) cannot be started
• WMI DCOM setup issues
• Expected default trustee or ACE has been removed from a DCOM or WMI security descriptor
• The ADAP status is not available
• One or more WMI connections failed
• Some GET operations\WMI class MOF representations\WMI qualifier retrieval operations failed
• Some critical WMI ENUMERATION operations\WMI EXECQUERY\WMI GET operations failed
• Some WRITE operations in the WMI repository\PUT\DELETE operations failed
• One of the queries of the event log entries for DCOM, WMI and WMIADAPTER failed
• Some critical registry key configurations for DCOM and/or WMI were reported

2 = WARNING

• System32 or WBEM folders are further in the PATH string than the maximum system length
• System drive and/or Drive type reporting are skipped
• DCOM has an incorrect default authentication level (other than 'Connect')
• DCOM has an incorrect default impersonation level (other than 'Identify')
• WMI service has an invalid host setup
• WMI service (SCM configuration) has an invalid registry configuration
• Some WMI components have a DCOM registration issue
• WMI COM ProgID cannot be instantiated
• Some WMI providers have a DCOM registration issue
• Some dynamic WMI classes have a registration issue
• Some WMI providers are registered in WMI but their registration lacks a CLSID
• Some WMI providers have a correct CIM/DCOM registration but the corresponding binary file cannot be found
• A new ACE or Trustee with a denied access has been modified to a default trustee of a DCOM or WMI security descriptor
• An invalid ACE has been found for an actual DCOM or WMI security descriptor
• WMI ADAP never ran on the examined system
• Some WMI non-critical ENUMERATION operations failed\skipped
• Some WMI non-critical EXECQUERY operations failed\skipped
• Some non-critical WMI GET VALUE operations failed
• Some WMI GET VALUE operations were skipped (because of an issue with the WMI provider)
• The WRITE operations in the WMI repository were not completed
• The information collection for the DCOM, WMI and WMIADAPTER event log entries was skipped
• New event log entries for DCOM, WMI and WMIADAPTER were created during the WMI Diagnosis Tool execution
• Some non-critical registry key configurations for DCOM and/or WMI were reported

3 = Command Line Parameter errors

4 = User Declined (Clicked the Cancel button when getting a consent prompt)

• WMIDiag is started on an unsupported build or OS version
• WMIDiag has no Administrative privileges
• WMIDiag is started in Wow environment (64-bit systems only)

When you run the WMI Diagnosis Tool via command line:

C:\>CSCRIPT WMIDiag.vbs

The generated report “%TEMP%\WMIDIAG-V2.2_WIN8.1_CLI.RTM.64_MYPC_2015.05.11_15.02.30-REPORT.TXT“ contains two types of figures:

• WARNING – Information that is useful if certain actions are executed
• ERROR – Problems that need to be solved to avoid errors reported by WMI

WMI DIAG 2.2 FAQ:

1. Where can I get the WMI Diagnosis Tool?

The WMI Diagnosis Tool can be downloaded from the Microsoft Download Center at http://www.microsoft.com/en-us/download/details.aspx?id=7684. More information about the WMI Diagnosis Tool usage can be found in the document (WMIDiag.doc) which comes along with the download.

2. Is the tool supported?

There is no official support for WMI Diagnosis Tool.

3. Can the WMI Diagnosis Tool diagnose a remote computer?

The WMI Diagnosis Tool is not designed to diagnose remote computers. This is due to the fact that WMI remote access is mainly based on the WMI infrastructure. Because the aim of WMI Diagnosis Tool is to diagnose WMI, the WMI Diagnosis Tool does not use WMI to perform its core operations. That’s why the WMI Diagnosis Tool must be run locally. However, the WMI Diagnosis Tool can be deployed remotely using Group Policy, Systems Management Server (SMS), or Microsoft Operations Manager (MOM) via a Management Pack. With Windows Vista, the WMI Diagnosis Tool can also be remotely executed through WinRM/WinRS, provided you configure and enable these features (WinRM/WinRS are not enabled by default). Microsoft SysInternals tool PSEXEC.EXE on Technet can also be used.

4. Does the WMI Diagnosis Tool fix problems it discovers?

No. The WMI Diagnosis Tool executes in read-only mode. Even though the WMI Diagnosis Tool diagnoses the situation and provides procedures to fix problems, at no time does the tool automatically fix a problem. This is by design, because the correct repair procedure depends on the context, the usage, and the list of applications installed on the computer.

I hope this new tool will help you identifying potential WMI issues in your environment. Don’t forget to read the support document (WMIDiag.doc) included in the WMIDIAG 2.2 download.

-Jeff

Hello AskPerf! Blake here with a quick blog to discuss an issue I’ve seen more frequently over the past few months. Here is the Scenario:

When you try and create a new Scheduled Task via the command line (schtasks.exe), the following error appears:

"WARNING: The task name "PERFTEST" already exists. Do you want to replace it (Y/N>?"

If you hit Y, then this message will appear:

"ERROR: Cannot create a file when that file already exists."

When you try and create the same task via the taskschd.msc snap-in, this message is displayed:

"An error has occurred for task test.  Error message: A task or folder with this name already exists."

When you click OK, the following error appears:

"Transaction support within the specified resource manager is not started or was shut down due to an error"

After you click OK, the task is not created.

Research internally as well as out on the Internet suggest that the Transaction Log is corrupted. To fix this you need to do the following:

1. Open up an elevated CMD prompt
2. Type in the following and hit enter: "fsutil resource setautoreset true c:\"
3. Reboot
4. After your machine reboots, you should be able to create new Scheduled Tasks now

NOTE I’ve only seen this on Windows 2008 R2 SP1 thus far, and will update this blog post if seen on other Operating Systems down the line.

Additional Resources

• Fsutil behavior

-Blake

Hello Askperf, my name is Naresh and today we are going to discuss how we can connect to a Windows 2012 Remote desktop collection from thin clients or other clients that are not session hints aware.

You might be thinking what are “Session hints”, so let us right away dig into the need for session hints. The connection broker in Windows 2012/R2 has changed the way clients connect to a group of RDSH/RDVH servers – earlier called farms but now we have them grouped as ‘collections’ in Windows 2012/R2. With Windows 2012, we brought changes in the way how the GUI looks, how we install different roles and how these different roles interact with each other. With all this the flow of remote desktop connections and how a client connects to the endpoint servers, changed as well.

Classical way of connecting to Remoteapps-windows server 2008 r2

In Windows 2008 R2 we deployed RemoteApps as:

1. MSI files
2. RDP files
3. Connect through RDWeb

To explain the connection flow I will walk you through the RDP file content of a RemoteApp in Windows 2008/R2 vs. Windows 2012/R2.

This is how a RDP file for a RemoteApp would look like in a 2008 R2 RDS environment:

1. The client reads the full address (of the farm) and the RDGateway properties.
2. If the client finds the RDGateway, it will authenticate against the gateway and based on the CAP and RAP policy the connection would be passed on.
3. The Client would then do a DNS query for the full address (of the farm) – assuming this is a DNS Round Robin or the farm name is pointing to a NLB – and would try to connect to the RDSH server. (If there is a dedicated redirector, then one of them will receive this connection.)
4. The RDSH (or the redirector) server receiving the connection would then contact the connection broker and if there is an existing disconnected session available for this user on an RDSH, the connection broker would send the details of the RDSH server back to the redirector. If there is no disconnected session, the connection broker would determine the best suited server as per the load balancing algorithms and would send the details of that server to the redirector.
5. Redirector would in turn pass those details to the client and the client would then directly logon to the application on the assigned server. Session established.

Change in the way we connect in 2012 -Session Hint / TSVUrl

In a 2012/R2 environment the RDP file looks like this:

1. In Windows 2012 the concept of Farms has been deprecated and replaced by collections. However, unlike Farms, collections do not have an entry in the DNS. Therefore the client reads the full address (which is for connection broker which hosts the RDS deployment and collections) and the RDGateway properties.
2. If the client finds the RDGateway, it will authenticate against the gateway and based on the CAP and RAP policy the connection would be passed on.
3. The Client would then do a DNS query for the full address, i.e. the connection broker for windows 2012 and would try to connect to the RD Connection broker. The term redirector is no longer used in Windows 2012 and instead connection broker does the redirection, but how?

What are session hints/TSVUrls ?

If you see the above RDP file, I have also highlighted the loadbalanceinfo which consists of the TSVUrl. A TSVUrl or session hints suggests which collection in the deployment the client should connect to. So along with the Full Address and gateway information, the client also reads the loadbalancerinfo and sends that over to the connection broker.

4. The connection broker then reads the TSVUrl to determine the collection name and then suggests which RD Session host participating in the collection should take the session based on whether there is an already existing session or not.

5. If there is an existing session available for this user on an RDSH in that collection, the connection broker would send the details of the RDSH server back to the client. If there is no disconnected session, the connection broker would determine the best suited server within the collection as per the load balancing algorithms and would send the details of that server to the client.

6. The client would then directly logon to the application on that assigned server. Session established.

DefaultTsvUrl: workaround for incompatible RDClient

However, what would happen if the RD client does not understand the TSVURLs? Yes, the client would directly logon to the connection broker but since the application is not hosted there, it would error out.

We have seen a lot of customers not wanting to move over to Windows 2012 Remote desktop services because they have Clients like, old thin clients with old RD clients and some non-windows clients or some of the old Windows clients that might not understand TSVURLs. I would highly recommend upgrading the clients to the latest by getting in touch with the OEM vendor/manufacturer for getting the latest RD client for these devices (in case of old Windows fat cients either install RDC 8 or later or else upgrade to the operating system that supports RDC 8) making sure they are tsvurl aware, given the so many other benefits and features the latest RD client would bring along. However, we do understand that some of our customers would have genuine reasons to keep these clients and also while planning and implementing an upgrade, one would need to run the show in the meantime with the non-compatible clients.

For such cases, we can use the below registry key on the connection broker hosting the deployment.

Important This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base 322756 How to back up and restore the registry in Windows.

The following tuning recommendation has been helpful in alleviating the problem:

1. Start Registry Editor (Regedit.exe).

2. Locate and then click the following key in the registry:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: DefaultTsvUrl
Data type: REG_SZ
Value data: tsv://<TSVURL>

This registry would provide the connection broker with the default loadbalanceinfo in case the client was unable to read the loadbalanceinfo provided in the remoteapp.

To find the TSVUrl to be set in DefaultTsvUrl, you can go to the following registry on the connection broker:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\<CollectionName>\Applications\<RemoteApp>\

RDPFileContents REG_SZ

You can find the tsvurl in the RDPFilecontents of the collection you would like to set as your default. Then configure it as your DefaultTsvUrl . You can then keep the show running while you upgrade to newer compatible clients.

NOTE: This is being suggested as an alternate/workaround when you do not have upgrading the client as an option. It has the following caveats that one should be aware of:

1. This would only be read when the client is unable to understand the tsvurl sent in the RDP file (from the remote app) and thus does not present the tsvurl to connection broker.
2. Whenever such a client comes the DefaultTsvUrl sends it to one single collection as specified in the registry value. DefaultTsvUrl can only point to one single collection only and thus you may want to plan and create a single collection for non compatible clients that has all their required apps in it. There is no provision of defining multiple collections in this registry so if you want to use incompatible clients over multiple collections then it won't be possible.
3. In case you change that collection, you will have to change the defauDefaultTsvUrl lttsvurl registry value as well.
4. This registry is only a workaround for tsvurls and will not work if the clients are not compatible with remoteapps itself. It is only for providing a workaround for clients that were able to access remoteapps earlier in Windows 2008/R2 but cannot access them through collections as explained in the section "Change in the way we connect in 2012 -Session Hint / TSVUrl".

-Naresh

Hello folks, as I’m sure you already know, Windows 10 will be available tomorrow, July 29th.  With that said, we will be blogging some of the new features that our team will be supporting in this new OS.

We will also blog about features that some of other teams support.  Namely, how to manage Windows 10 notifications and upgrade options:

How to manage Windows 10 notification and upgrade options

Windows 10 landing page

See you soon!

-Blake

Hey Folks, quick post to let you know that the Windows 10 Remote Server Administration Tools are now available.

Remote Server Administration Tools for Windows 10

Details

Remote Server Administration Tools for Windows 10 includes Server Manager, Microsoft Management Console (MMC) snap-ins, consoles, Windows PowerShell cmdlets and providers, and command-line tools for managing roles and features that run on Windows Server Technical Preview.

Remote Server Administration Tools for Windows 10 can be used to manage roles and features that are running on Windows Server Technical Preview, with the following exceptions:

• DHCP Tools. Dhcpmgmt.msc is not available in this release of RSAT, but equivalent Windows PowerShell cmdlets are available.
• IP Address Management (IPAM) Tools. IPAM tools are not available in this release of RSAT.
• Network Policy Server Tools. The NPS console is not supported on a Windows client-based operating system, and will be removed from future releases of RSAT.
• Routing and Remote Access Tools. Routing and Remote Access Tools that are GUI-based cannot be used for remote configuration in this release of RSAT, but the equivalent Windows PowerShell cmdlets are available.

-Blake

Hello AskPerf! My name is Matt Graham and I'll be discussing an issue that you may see on your RDS Licensing Server.

SCENARIO You have both a 2008 R2 and an 2012 or 2012 R2 Licensing server in your RDS environment.  When you look under services.msc, you notice that the Remote Desktop Licensing service is stopped on the 2012 / 2012 R2 server.  You try to start it again, but after a short period of time (30 seconds to a few minutes) it stops on its own again.  In fact, every time you try to start the service, it starts for a short time and then stops on its own.

Alternatively, you may see this service crash.

ISSUE This behavior is actually by design.  You cannot have a 2008 R2 and a 2012 / 2012 R2 License server in the same RDS environment.

RESOLUTION If you are moving to a 2012 / 2012 R2 environment, then deactivate and decommission your 2008 R2 license server.  If you still want to have two or more license servers, you will need to build another matching 2012 / 2012 R2 license server.

CONSIDERATION #1 We have seen at least one case where the 2012 License Manager Service still did not start even after removing the 2008 R2 License server.  In this case, the licensing server database had become corrupt.  If this happens, you can rebuild the database using the "Manage Licenses" wizard.

WARNING If you do this, you will have to re-install your licenses after the rebuild. Be sure you have your licensing information.

1.  Open your RD Licensing Manager, right click on your server and select Manage Licenses.

2. Select Rebuild the license server database.

3.  After this, you will need to have your Retail CAL pack or your EA information in order to reinstall your licenses.

CONSIDERATION #2 In one case, a customer had to rename the "C:\Windows\System32\Lserver" folder, uninstall the RDS roles, reboot, and reinstall the RDS Licensing role in order to get the service to start again.  This should effectively do the same thing as rebuilding the license database, but I mention it because it was successful in at least one case.

Finally, when you decommission your old 2008 R2 server, be sure to think through what that will entail for your session hosts.  You may need to take inventory of your session hosts and ensure that they are pointed to your 2012 / 2012 R2 license server if they aren't already pointed to it.

-Matt

Hello AskPerf!  My name is Susan, and today we are going to discuss an issue where printing through Office applications only produce 1-2 pages out of a multi-page document.

For example, you have Windows 2003/2008 Print Server with (e.g. Lexmark Universal v2 PS3 (2.2.5.71)) and Windows 8.1 clients attempt to print from Office applications; only the first page or 2nd pages will print. 

Other symptoms you may observe:

• You can print only 2 pages, for example: page 2-3 of a 10 page document
• You print just fine out of other applications
• If you print to PDF from Office, the files print as expected

Cause There are two main causes of the behavior above.  The first is missing fonts from the Print Server – the buffer simply fills and overflows and only ~2 pages will print.  The second cause is a legacy Bluetooth service is installed as well as its add-on component.

Resolution #1

Install the missing fonts on the Print Server.  You do not need to install Office, only the fonts.

Here are the fonts that should be installed:

Fonts that are installed with Microsoft Office 2013 products

Fonts supplied with* Office 2010

Office 2010 printing errors with Calibri font when printing through a Windows Server 2003 or 2008 print server

Resolution #2

For the Bluetooth Driver, there are two pieces: the service as well as the add-on that is registered under the Office applications.  The add-ons should be disabled for all Office applications under multiple keys.

Option 1

1. Check with the vendor to determine if there are any updates to your Bluetooth device.

Option 2

1. Uninstall Bluetooth       

a.      Please confirm it is completely uninstalled via checking MSCONFIG and running Services.msc

b.      Next, you will need to modify registry keys in two  locations  and change the loadbehavior to 0 or delete. 

           For example: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\AddinsBtmoffice.connect

And also under  BTMOffice.connect is loaded in Access, Excel, Project, Outlook, Powerpoint, Word for each application.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\Access\Addins\AddinsBtmoffice.connect

And also under  BTMOffice.connect is loaded in Access, Excel, Project, Outlook, Powerpoint, Word for each application.

Option 3

1. Disable Bluetooth as a test

a.      Stop the service from running in Services.msc

b.      Change the loadbehavior in the above registry keys to 0

-Susan

Hello AskPerf!

Wanted to send you a very long overdue note on the current status of the AskPerf Blog site. We are in a transition period on ownership of this blog site going forward. I personally have moved on to another team, and the remaining Performance folks have as well. With that said, a decision will be made hopefully soon, on the future of this blog.

Thank you as always for your support and active participation in our posts.

-Blake