31 August 2010

Export TMG proxy logs to w3c while maintaining native reporting

When I implemented the new TMG 2010 infrastructure I was only moderately impressed by the native reporting.  Following TMG SP 1 this changed a bit.  There were some "Significant enhancements to the reporting.  For more details on this check out:


Grand, so for this first time TMG actually generated a report worth keeping.  But now here is the catch.  In ISA server you could export to w3c files and it would not make much difference.  In TMG if you switch to w3c logging you loose the ability to generate reports.  You also loose the ability in the logging filter to specify anything other than Live.  This is actually a problem.

So in short you want to use a 3rd party log analyser you will loose out on the native functionality.

Unless you can come up with a cunning plan.

Here is what I ended up doing.

  • I log directly to the native SQL2008 Express.
  • I then have a scheduled task that executes a script that runs a modified  SQL to W3C Conversion script
  • I can then pick up my exported files for processing.
The conversion script is MSDEtotext.vbs

It is one of the tools available form here :

Two things to look out for:

If importing into webspy there is and additional vbcr that breaks the import
The bytes sent and received are reversed. Webspy has made this an option in their loader now.

I have fixed these in my scripts but just be aware of them.

Drop me a mail if you want them.

Specifying Multiple values for UAG fields

For some reason it is very complicated to do just about anything in UAG. I need to publish multiple servers through my TS Client Tunneling application.

By default there is only space to name 4 servers. 
To overcome the 4 line limit  you need to press the "Insert Key" this will provide a new line for to to be able to enter your information.

Yes simple enough, just really not intuitive.

According to this post http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/9019abaf-1743-4163-8bbd-b129e7bda19d/#2e2b59d7-3357-4ac7-a7cc-f37013223411 If you want to name more servers you need to user a regular expression.

This got me thinking and searching.There is a load of information about regular expression available on :
http://technet.microsoft.com/en-us/library/dd282903.aspx  There is a library of regular expressions or regex. This site even includes a very handy  regex tester  http://regexlib.com/RETester.aspx

I would like to add a wild card address here so I can connect to any machine in my domain. Something like*.mydoman.com

The regex for this would be [a-z0-9]*\.mydomain\.com

But when I try this I get nowhere.  This is because in my case a regular expression cannot be specified.  There are other places where you can specify regular expression but you have to explicitly define it as a regular expression

Here is the option during the application publishing wizard.

Here is the option when editing and existing application

Hope this helps to save someone some time and effort.

30 August 2010

Configuring Remote Desktop Certificates and Eliminate Certificate Warnings

We have all been faced with the annoying warning message when connecting to an RDP server it's a warning concerning  -- something about a certificate yada yada yada....

If we have a closer look at it we can see what it is actually moaning about.

"The identity of the remote computer cannot be verified. Do you want to connect anyway?"
This tells us what the problem is but we need to look a little further down to see Why it cannot verify the identity/

The Certificate name section is correct - the server name and domain are correct, so why the warning.  we need to look further down.
Certificate errors section informs us that  "The certificate is not from a trusted certificate  authority."

To view the offending certificate click on the "View Certificate..."  button.

The "Issued to:" Line is fine. the problem comes with "Issued by:"  If you have a trusted Certificate authority you will not get this warning.

Cool  - So now we know What the problem is and why there is a problem.

Lets go about fixing it.

There is a very detailed article here: http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx

Basic steps are:
Configure the correct Certificate Template on your internal Certificate Authority.
Either manually enroll your server for a cert - or set the group policy to auto enroll. The latter being the recommended.

So great. We have avoided one annoying security prompt, what's the big deal?  Well the big deal comes on when you start publishing your servers and they need to be connected via Remote desktop connection broker or a Remote Desktop Gateway or through a UAG or TMG publishing rule.  These `security warning can cause all sorts of problems from breaking Single Sign On (SSO) to preventing your connection from being established at all.

Don't believe me?  check out: http://blogs.technet.com/b/fsl/archive/2010/07/15/issues-with-remoteapp-and-remote-desktop-publishing-through-uag.aspx

27 August 2010

Attempting to Publish Remote Desktop Services or RemoteApp through UAG

So just to give some background on this one.

I have built a fully functional RDS environement

I have one server that is the Gateway Web access and the connection broker.
Then I have two machines as session hosts in a round robin dns.

My environemnt works great internally and even when publish through tmg is working great.  Now i am attempting to publish this through UAG

I follow the guide on Technet  http://technet.microsoft.com/en-us/library/ee441339.aspx

When I attempt to connect from a Windows 7 machine it just sits there, no error or time out.
When I attempt the same connection form a Windows 2008 R2 machine I get his error:

"To use this program or computer, first log on to the following website:" <UAG trunk>

It does not really seem to matter what settings i chnage the same error keeps popping up.

Any Ideas?

26 August 2010

IIS and TMG default site redirection

I have just finished publishing Remote Desktop Services Web Access.  as part of "finishing it off" I like to make sure that there a redirects in place.

We want to make sure that users don't end up on this page:

First up we are going to tackle the internal.  This is quite simple.

We open up the IIS management console. On the default site we open up HTTP redirect.

  • Check "Redirect request to this destination"

  • In the RDSGW case I simply added "/rdweb/"

  • But the rest is pretty self explanatory

That's it - done - no custom pages or scripts  - just that.

Next We have to do a redirect for the External users coming in from the Internet.

I am going to do the redirect on the TMG server.

  • First I create a listener that listens on the correct external IP address.

  • I select HTTP as the traffic type

  • Then I create a rule with the action as Deny

  • Then I specify the redirect


Also pretty simple.

The result is that people will never end up on the IIS start screen.  You application and work will look professional.  Makes me wonder why everyone does not do this....

Publish RDS Gateway through TMG

Getting your RDS environment to work internally can be a difficult and time consuming task.  However once you have successfully tested it from your internal network it is fairly easy to publish it with TMG

To test to see if your RDS gateway is working you need to un-check the "Bypass RDS Gateway for Local Addresses" This needs to be done on the RD Session Hosts and the Connection Broker

If this works fine for you then you can go ahead an publish.  

  • Re-check the "Bypass RDS Gateway for Local Addresses" on Session Hosts and the Connection broker. 
  • Export your certificate that you are using for the RD Gateway and install it on the TMG servers.

Create a SSL Listener

  • I specify a IP address for the Listener
  • Enable HTTP and SSL connections
  • For HTTP to HTTPS redirection select redirect all traffic from HTTP to HTTPS
  • From the Certificates tab select "Use a single certificate for this web listener" and select the certificate you installed earlier
  • Authentication is "No Authentication"
Next you need to create the publishing rule

  • Allow
  • From Anywhere
  • to - your RDSGW - Forward original host header - request appear to come from TMG
  • Traffic HTTPS
  • Listener - use the one created earlier
  • Public name - Make this the same as public dns name
  • Paths need to at least include /rdsweb/* and /rpc/*
  • Authentication delegation - "No Delegation, client may authenticate directly"
That's it.

I am going to include the screen shot of the listener and rules, just in case.

And here are the screen shot for the TMG rule


I know this was really spelling it out - but when I was struggling I wished there was someone that could just confirm that something was configured right.

If you need to publish your Gateway in a DMZ or perimiter environemnt here is a very nice detailed article

RDS Gateway Certificate troubleshooting "certificate subject name do not match"

I tried for a few hours to figure out why my sessions could not authenticate.

I kept on getting prompted for credentials.  I figured it was an issue with the certificate I was using so I switched them around.  This I was sure was going to work but then I got another error.

“This computer can’t connect to the remote computer because the Terminal Services Gateway server address requested and the certificate subject name do not match. Contact your network administrator for assistance.”

This allowed me to find this this article  --- EVENTUALLY  http://blogs.msdn.com/b/rds/archive/2008/12/18/ts-gateway-certificates-part-iii-connection-time-issues-related-to-ts-gateway-certificates.aspx

In my case my certificate I retrieved form our internal CA  only had a  "User Principal Name" specified for the Subject Alternative name and not a "DNS name"

The article does not mention this explicitly - I just spotted it by going through my cert.  The big problem is this it worked for everything other then using the gateway.  Single Sign on worked - sessions worked.

Just goes to show  - certificate can be a problem if they are not EXACTLY right.

25 August 2010

Managing your larger RDS environment using Group Policy

Manually keeping a few server configured can be fairly easy but if you have a large RDS environment this is just not practical or recommended.

Speaking form personal experience - sooner or later one of them gets away from you and then your environment is out of sync.

Luckily there is an answer that comes in the form of group policy.  There is an extensive list of policies that can be applied to manage everything from Session limits device Redirection etc. you can for instance automatically join RD Session hosts servers to a Connection Broker farm with a policy.

There are also settings here that are not accessible through the MMC consoles.  Such as "Turn off Fair CPU Scheduling"  the only other way to turn this off is the manually edit the registry per host.

There is a complete ref here:  http://technet.microsoft.com/en-us/library/cc753697(WS.10).aspx

A nice way to be able to test this is by editing the local policy on a specific machine. or by having a test policy that you can apply to a few test machines.

One important note: remeber what setting you set where.  Some setting can be set in Remote App manager and the same one are available in group policy.  generally speaking group policy will always win.

So just be aware of this in case you start to see unexpected behaviour.

Keeping your RD Session Hosts in Sync

When you have more than one Remote Desktop Session Host you may want to keep the configuration the same across the server.  You would want to do this if they are load balanced and you are using them as generic farm members.

You would not want to keep them in sync if you are using specific application on specific servers and you are using session hosts as your application source.

The place to do this is from the RemoteApp Manager mmc console.

Most obvious setting you would want to sync is the published applications.

But you also want to make sure that your RDP connection setting are the same to ensure a consistent environment. This can be changed in RDP Settings

You might also want to specify some custom RDP settings. (http://technet.microsoft.com/en-us/library/ff393699(WS.10).aspx)

Once your configuration is done or update you want to sync to another RD Session host.

From the Actions Menu on the Right hand side of the Remote App manager MMC select Export Remote App Settings.

You will be given an option to export your settings to another RD Session Host Server or to export to a file.
By exporting directly to another server you are putting them in sync.

You can also do the reverse my importing form another server or by importing a configuration file.

RDS Gateway, Connection Broker, and Web Access deployment with SSO

This is just a really short version of how I got all of the above to work.  (This I just a ref for myself but someone else might find it useful.

1 Server for Web Access, Connection Broker and Gateway (RDS01)
2 Server for RDS Session host (RDS02 and RDS03)

Before I started:
  • I requested an exportable certificate form my internal CA.  I then installed that certificate eon the three servers I was using. 
  • I Created a DNS entry that matches the CA common name for use with the Gateway and Web Access
  • I created a round robin DNS entry for the two RDS Session hosts.

Install RDS Session Host Role on RDS02 and RDS03 the following was done on both machines
  • Configure Remote App Management
  • Used the certificate that I pre-installed to digitally signs apps.
  • Specify Gateway setting to Use gateway and Ask for Password
  • Added RDS01 to the TS Web server groups
  • Publish a different app on each host
On server RDS01
Install the RD Gateway Role Service
Install the RD Web Access Role Service

Use the pre-installed certificate for the authentication.

Tested and everything was working 100% with SSO (Just a note  -- Test from another machine no one that has rdp sessions open to the TS Hosts.)

Next step was to add the TS connection broker role service to RDS01

  • Add the Webb access Server to the TS Web access Server local group
  • Add the RDS Session Host Roun Robin DNS in the Application source
  • Specify the certificate to use (the pre-installed one)
  • Change the gateway setting to RDS01 and Ask for a password
  • Add RDS02 and RDS03 in to connection broker group.
  • Change the application source on the web interface to use the connection broker

ON RDS02 and RDS03
  • In the connection configuration
  • Join both machines to the Connection broker farm
  • Select IP redirection
  • In remote app manager chnage the RD Session host server settings server name to use the NLB dns

Two Things:

When I connect to an application I get a certificate warning from the machine stating that the certificate name doe snot match the connection name -- hardly surprising since we are now using an NLB name.

Secondly when I update applications - I need to go to the Connection broker and re add the App source.

--- Update ---

I have discovered that there is an issue with Windows 7 connecting to the RDS with SSO.  To test you can use Vista and Win 2008 R2

The issue I finally found to resolve the Windows 7 issue was a group policy setting on the RDS servers.

You need to ensure that  the following is not overwritten

Computer Configuration - Policies - Windows Settings - Security Settings - Local Policies / Security Options

"Network Access: Do not allow storage of passwords and credentials for network authentication"  - This need to be set to DISABLED

"Network Security: LAN  Manager authentication level" needs to be set to "Send LM and NTLM -Use NTLMv2 session security if negotiated"

23 August 2010

Buildng a RDS Load Balanced Farm with a RD Connection Broker

I am not going to lie about this one.  This is my third attempt to write this article.

I generally believe in an learn as you explore approach, in this particular case it just does not work.  There are too many thing that are not intuitive enough to just to be able to "figure it out." 

The only way I managed to get this going was by following the technet documentation on:
http://technet.microsoft.com/en-us/library/ee221120.aspx  Although this is accurate and works it is not always easy to follows.  So I am basically just going to redo some of it here with a few screen shots.

Remote Desktop Connection Broker (RD Connection Broker), formerly Terminal Services Session Broker (TS Session Broker), is a role service that provides the following functionality:
  • Allows users to reconnect to their existing sessions in a load-balanced RD Session Host server farm. This prevents a user with a disconnected session from being connected to a different RD Session Host server in the farm and starting a new session.
  • Enables you to evenly distribute the session load among RD Session Host servers in a load-balanced RD Session Host server farm.
RD Connection Broker keeps track of user sessions in a load-balanced RD Session Host server farm. The RD Connection Broker database stores session information, including the name of the RD Session Host server where each session resides, the session state for each session, the session ID for each session, and the user name associated with each session. RD Connection Broker uses this information to redirect a user who has an existing session to the RD Session Host server where the user’s session resides.

If a user disconnects from a session (whether intentionally or because of a network failure), the applications that the user is running will continue to run. When the user reconnects, RD Connection Broker is queried to determine whether the user has an existing session, and if so, on which RD Session Host server in the farm. If there is an existing session, RD Connection Broker redirects the client to the RD Session Host server where the session exists.

With RD Connection Broker Load Balancing, when a user without an existing session connects to an RD Session Host server in the load-balanced RD Session Host server farm, the user will be redirected to the RD Session Host server with the fewest sessions. If a user with an existing session reconnects, the user is redirected to the RD Session Host server where the user’s existing session resides. To distribute the session load between more powerful and less powerful servers in the farm, you can assign a relative server weight value to a server.

RD Connection Broker components

There are two RD Connection Broker components to consider in a load-balanced RD Session Host server farm.

RD Connection Broker server. This is the server that runs the Remote Desktop Connection Broker service and tracks user sessions for one or more load-balanced RD Session Host server farms. RD Connection Broker uses a farm name to determine which servers are in the same RD Session Host server farm.

RD Session Host servers that use RD Connection Broker. These are RD Session Host servers that are members of a farm in RD Connection Broker. To participate in RD Connection Broker, a server must meet the following criteria: 
  • The server must have the RD Session Host role service installed.
  • The server must be a member of an Active Directory domain.
  • The server must be a member of the Session Broker Computers local group on the RD Connection Broker server.
  • The server must be a member of a load-balanced RD Session Host server farm.
Task required to Configure a Load balanced RD Connection Broker:

  1. Install the RD Connection Broker role service on the server that you want to use to track user sessions for a farm.
  2. Add the RD Session Host servers in the farm to the Session Broker Computers local group on the RD Connection Broker server.
  3. Configure the RD Session Host servers in the farm to join a farm in RD Connection Broker, and to participate in RD Connection Broker Load Balancing.
  4. Configure DNS round robin entries for RD Session Host servers in the farm

Task 1 : Install the connection broker role service

If the Remote Desktop Services role is already installed:
  • Under Roles Summary, click Remote Desktop Services.
  • Under Role Services, click Add Role Services.
  • On the Select Role Services page, select the Remote Desktop Connection Broker check box, and then click Next
 I have two servers in my lab environment this is what they are configured with;



TASK 2 : Add the RD Session Host servers in the farm to the Session Broker Computers local group on the RD Connection Broker server.

To add an RD Session Host server to the Session Broker Computers local group on the RD Connection Broker Server
  • On the RD Connection Broker server, click Start, point to Administrative Tools, and then click Computer Management.
  • In the left pane, expand Local Users and Groups, and then click Groups.
  • In the middle pane, right-click the Session Broker Computers group, and then click Properties.
  • On the General tab, click Add.
  • In the Select Users, Computers, or Groups dialog box, click Object Types.
  • Select the Computers check box, and then click OK.
  • Locate and then add the computer account for each RD Session Host server that you want to add.
  • When you are finished, click OK.
On RDS01

TASK 3 : Configure the RD Session Host servers in the farm to join a farm in RD Connection Broker, and to participate in RD Connection Broker Load Balancing.

You can configure a Remote Desktop Session Host (RD Session Host) server to join a farm in RD Connection Broker, and to participate in RD Connection Broker Load Balancing, by using the Remote Desktop Session Host Configuration tool.

On every one of the RD Session Host Server that need to join the farm perform the following:

  • Get your Farm name ready: know what you are going to call the farm.
  • On the RD Session Host server, open Remote Desktop Session Host Configuration. To open Remote Desktop Session Host Configuration, click Start, point to Administrative Tools, point to Remote Desktop Services, and then click Remote Desktop Session Host Configuration.
  • In the Edit settings area, under RD Connection Broker, double-click Member of farm in RD Connection Broker.
  • On the RD Connection Broker tab of the Properties dialog box, click Change Settings.
  • In the RD Connection Broker Settings dialog box, click Farm member.
  • In the RD Connection Broker server name box, type the name of the RD Connection Broker server.
  • In the Farm name box, type the name of the farm that you want to join in RD Connection Broker.
  • Click OK to close the RD Connection Broker Settings dialog box.
  • To participate in RD Connection Broker Load Balancing, select the Participate in Connection Broker Load-Balancing check box.
  • Optionally, in the Relative weight of this server in the farm box, modify the server weight. By default, the value is 100. The server weight is relative. Therefore, if you assign one server a value of 50, and one a value of 100, the server with a weight of 50 will receive half the number of sessions.
  • Verify that you want to use IP address redirection. By default, the Use IP address redirection setting is enabled. If you want to use token redirection mode, select Use token redirection. For more information, see About IP Address and Token Redirection.
  • In the Select IP addresses to be used for reconnection box, select the check box next to each IP address that you want to use.
These can also be set using group policy http://go.microsoft.com/fwlink/?LinkId=138134

I Perform this on both RDS01 and RDS02

Task 4 : Configure DNS round robin entries for RD Session Host servers in the farm

(For configuring with NLB check http://fixmyitsystem.com/2011/06/rds-load-balanced-farm-with-rdcb-using.html)

To load balance sessions in an RD Session Host server farm, you can use the RD Connection Broker Load Balancing feature together with Domain Name System (DNS) round robin. To configure DNS, you must create a DNS host resource record for each RD Session Host server in the farm that maps the RD Session Host server’s IP address to the RD Session Host server farm name in DNS.

The following procedure provides the steps to configure DNS on a Windows Server 2008 R2-based domain controller.

You must be a member of the Domain Admins, Enterprise Admins, or the DNS Admins group to complete this procedure.

To add DNS entries for each RD Session Host server in the farm  
  • Open the DNS snap-in. To open the DNS snap-in, log on to a computer where the DNS snap-in has been installed, click Start, point to Administrative Tools, and then click DNS.
  • Expand the server name, expand Forward Lookup Zones, and then expand the domain name.
  • Right-click the appropriate zone, and then click New Host (A or AAAA).
  • In the Name (uses parent domain name if blank) box, type the RD Session Host server farm name.

The farm name is the virtual name that clients will use to connect to the RD Session Host server farm. Do not use the name of an existing server. For management purposes, we recommend that you use the same farm name that you specified when you configured the RD Session Host servers to join a farm in RD Connection Broker. (In my case it is RDSFARM)
  • In the IP address box, type the IP address of an RD Session Host server in the farm.
  • Click Add Host.
  • Repeat steps for each RD Session Host server in the farm.
 So now we need to check if the farm exists.

Open Remote Desktop Services Manager
Right Click Remote Desktop Services Manager and select Import from RD Connection Broker
add the FQDN of the Connection broker server (in my case RDS01)

Now we can expand the tree under RD Connection Broker and we will see our farm that we have just created.

   ---  Updates  ---

On each of the server you will also need to go to the Remote App Configuration.

Go to the Remote App Deployment settings
Connection sesttings.
Change the FQDN to the FQDN of the Farm name

Added article on configuring with NLB  http://fixmyitsystem.com/2011/06/rds-load-balanced-farm-with-rdcb-using.html

20 August 2010

Adding additional servers to your RDS environment

In a few of the past articles I have looked at various Remote desktop Services and the various Role services.

By now I have the following.

1 RDS server
RDS Web Access
Remote Desktop gateway to enable SSL connections from the outside

So now I would like to add an additional server for two reasons. 

Improve the scalability of the service
Improve the fault tolerance of the service.

Fist step add another RDS Session host.

  • I build another server and only install the Remote desktop Session host role.
  • I then request and install a certificate
  • In the RemoteApp Manager is use that certificate for "Digital Signature Settings"
  • I then add the Original and new server names to the "TS Web Access Computers" group
  • Then I publish calculator on my new server.
Secondly to configure Remote Desktop Web Access to retrieve application for the new server.

  • Log into the remote Desktop Web Access with administrative rights (Member of the TS Web Access Administrators group)
  • Select the Configuration link
  • Select  "one or More RemoteApp sources
  • Add the FQDN for the older server the a semicolon and then the new server eg oldserver; newserver
If I check out the Programs I can now see my old app and the new Calculator application published on the new server.

Great.  You now have a way of adding additional server an application to your Web access.

This is where it gets interesting though.

If I publish Calculator on the old server I now see two version of the application.  This is actually not very surprising because the web access is simple enumerating published applications from the RD session hosts.  We at this point don't have a "load balance" or "farm" to aggregating things for us.

So this is where the Connection broker Role Service comes in.

"Remote Desktop Connection broker supports session load balancing and session reconnection in a load balancedRD session host server farm.RD Connection Broker is also used to provide users access to RemoteApp programs and virtual desktops through Remote App and Desktop Connection"

For a full deployment guide check out http://www.microsoft.com/downloads/details.aspx?familyid=DF3E1876-737E-4F81-9F29-828A67EBBF58&displaylang=en

I will be covering this deployment myself in a later post.

Error when listing or trying to change Server Roles or Features

When I logged onto one of my test servers today and I tried to add an additional role I found this problem:

There is a Error where my roles should be.  The same for Features.

Clicking on Error Details gives me the following:

"Unexpected error refreshing Server Manager: The remote procedure call failed. (Exception from Hresult: 0x800706BE)

For more information see the event logs..."

So I go and check the event logs and find:

Log Name: Application

Source: Application Error
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Faulting application name: TrustedInstaller.exe, version: 6.1.7600.16385, time stamp: 0x4a5bc4b0
Faulting module name: ntdll.dll, version: 6.1.7600.16559, time stamp: 0x4ba9b802
Exception code: 0xc00000fd
Fault offset: 0x0000000000052880
Faulting process id: 0x564
Faulting application start time: 0x01cb405fab8285ce
Faulting application path: C:\Windows\servicing\TrustedInstaller.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: ed4f54be-ac52-11df-8152-00155dacb410

In the system log I find a probably related event:

Log Name: System

Source: Service Control Manager
Event ID: 7031
Task Category: None
Level: Error
Keywords: Classic
User: N/A
The Windows Modules Installer service terminated unexpectedly. It has done this 2 time(s). The following corrective action will be taken in 300000 milliseconds: Restart the service.

I can start the service without any problems but when I run a refresh of the roles or features the service fails .

Not to be out done by a simple failed Service I thought I would head over to the Powershell.  But no luck here either:

Thinking about it, not really that unexpected since the underlying mechanism being used by both of these process is in trouble.

I found an article that recommended Running the following patch update file would resolve the problem:  Windows6.1-KB947821-v5-x64.msu  available from http://support.microsoft.com/kb/947821

Download the 95Mb update and install. And just like that the problem is resolved - not even a reboot required.

Both server manager and Powershell is working again.

19 August 2010

Requesting a certificate from a local CA on TMG or UAG

It is almost inevitable that you will get to the point where you need to install local CA certificates to your TMG or UAG server.

Normally the process is pretty straight forward. 
  • Open MMC
  • Add the Certificates Snap In
  • Select Computer Account
  • Expand Certificates to  - Personal - Certificates
  • From the conext menu of Certificates select Request New Certificate

The certificate templete I use requres me to manually configure the following two fields

common name
user principal name

Your request will fail since the RPC request will be dropped.

To allow the request to go through you might have tried to careat a allow all rule to the internal CA but this will also fail. The reason is there is a system policy firewall rule that is applied first that would block the request.

Opem the TMG management consloe and edit the system policy

Under Auntintication services - Active Directory you need to Uncheck Enforce Strict RPC compliance.

I also added a user defined protocol:
TCP Outbound :1131

And allowed it from localhost to the Certificate Issue server.

I found what was being blocked by checking the logging.  I set the filter for source netwro = localhost and destination network = internal  Then i checked for dropped requests when I requested a certificate.

If you realy, really get stuck and find yourself in a pinch and you really, really need to get a cert on there ASAP the quick and dirty way is to stop the Microsoft Forefront TMG Firewall service.  Just disable your external network first.

ISA 2006 Link Translation for a published site

I have on a number of occasion had to deal with trying to publish internal web applications to the Internet.

Typically there are a few problems that need addressing.  But the one that used to really got me was link translation.

If your application's internal dns name is internal.domain.com your external would be external.domain.com.  This depending on the application could be a problem.  If the application is configured to use relative path then you are fine.  If it is configured to use absolute paths you are going to have problems.

Relative paths ignore the hostname section because all the links are \path\path\pasge.htm
Absolute paths include the hostname http:\\internal.domain.com\path\path\page.htm

In this case you need to be able to translate the output from the application for it to work externally.  The concept if fairly simple but to actually get it working properly took me a while and a bit of luck to figure out.

My example uses the following

Internal name  = internal.domain.com
External name = external.domain.com
Internal = http
External = https

Since the problem is with FQDN it makes sense to always use the FQDN if you don't your translation won't work. Trust me.

The public name will be different and it is of course best practise to limit request to the actual site name that will be used. Also if you have request coming in on any other name not that you would be allowed to do this your translation will not work either.

  • On the link translation tab.
  • Check Apply link translation to this rule
  • Select Configure
  • Select Add or Edit
  • Specify the FQDN of the original and the translated address.

That's it. Not too complicated.  But if you err in any of the fields or make a typo  the translation will not work.

17 August 2010

Gain total control over your remote application .rdp files

Ever wanted to change as much as possible in the actual rdp file?

Here is the complete reference from Microsoft

I used to edit the ica file for my Citrix server to really try and squeeze every little bit of performance out of the sessions.  This is pretty much the same. Except of course the setting are different.

What I am going for is to reduce the bandwidth requirements as much as possible. My network has relatively low latency but bandwidth is limited.  And as we know by now whenever a remote session is constrained from a bandwidth perspective you automatically increase your latency and as soon as your latency goes up your session's user experience degrades.

Some of the fields are already in the rdp file but most of them you will have to add. these re the ones I edited or added
  • bitmapcachepersistenable:i:1 
  • compression:i:1
  • disableprinterredirection:i:1 
  • session bpp:i:8
Certain fields cannot be change or they need to be change together with another field.  If a problem occurs you get a very friendly RDP file has been corrupted warning.

If you are publishing your Remoteapp through UAG there is another place to edit fields.  I have not gone into this myself yet but here is the link in the meanwhile. 


How to enable 8bit or 256 colours for remote applications

Don't get me wrong I love colours lots of them, the more the  better.  But when it comes to RDP, remote app, ICA, VNC, etc you really do not want to use more colours than are necessary.

Let me explain:

8 Bits = 256 colours
15 Bits = 32,768 colours
16 Bits = 65,536 colours
24 bits = 16,777,216 colours

If your remote application is a command line utility like notepad or a command shell you really only need two colours  - black and white.

When you remote application is a graphic application you want more colours - ideally something that is close enough to true colour so that you can't tell that there are "colours missing"

The catch comes when you need to add those colours to your remote data stream.  the more colours you need to render the more data you need to send.  Terminal server used to support 256 Colours or 8 bit colour.  This has slowly disappeared over time and now you actually need to scratch around to find a way to enable this.  Why? You may ask, well few applications today render "nicely" in 8 bit and network performance has increased to the point where this is probably not necessary anymore.  Here in South Africa of course we still have plenty of slow WAN connections so I would still like the option of using 8 bit colour for my very simple text only applications.

So how do we enable 256 colours?

Remote apps are .rdp files that are generated that contain the relevant information for launching that application.  These are plain text file and can be edited in notepad.

In Remote app manager you can add another application.  I am going to use paint.

Now you can "Create .rdp File"  Save this file and then open it with notepad  -- or open notepad and drop the file onto notepad.
You will note that there are many lines of setting and if you look closely they will actually start to make sense.
The one line we are interested in is

session bpp:i:15

That is the line that sets the maximum colour depth.  15 is the default for 15 bit if we change this to 8 for 8 bit it will reduce the number of colour used.

Save the file and launch the application.  From another machine - not through your rdp session.

Your application session is now running in reduced colours.  That's great but how do we get this into our web access?

When publishing a remote app, rdp files are generated and placed in these two locations:


Edit these corresponding files without changing the file names and it will change the file that the client will launch and this will give you the reduced colours you are looking for.

This will however not "work" for all your applications  - case in point - Paint, it just looks terrible.

8 Bit version
15 bit version

!! GOTCHA's !!

Ok so when you are busy testing this stuff you might find that you sometimes get mixed results and sometimes thing don't make any difference.  This is because sessions can be shared to the same host.  So if you have an application open on 15bit the next application will launch on the same session without creating a new reduced colour session.  Make sure you disconnect all session before testing.  Or use your buddy as a lab rat...

Sharepoint Web application recovery from a SQL backup

I have a MOSS 2007 server that is not really in active use but of course we have a few users that trust their lives to some of the content on there.

I had a user delete a site by accident.  Great! Now what?

I check to see if my stsadm backup that is set to run with a script and a scheduled task succeeded the night before  - no luck  - this has not run for about 2 weeks. ( I did say it is not really active)

So last hope was to check the SQL backups.  Thankfully this succeeded the night before. 

So the recovery path would be as follows.

  • Create a new database
  • Restore backup of the original database to the new one
  • In SharePoint Central Administration under Application Management remove the current content database.
  • Using stsadm attach the new content database
  • Run IIS reset
  • Check the site to see if everything is working 100% and that the missing site is back.
The stsadm command I used was:

stsadm.exe -o addcontentdb -url -databasename -databaseserver

Some notes about my not so successful recovery attempts:

If you attach the recovered content database to the application before removing the old one the sites "that are duplicates" will be ignored by Sharepoint.

If you get your user to see if her content is back before running IISreset you will look like you don't know what you are doing because the missing site will not show up yet.

16 August 2010

SharePoint stsadm backup error 15105

I was asked to do a manual stsadm backup for a supplier that needed a copy of our environmet.  Okay so I am a little rusty with the stsadm tool and struggled a bit to get it going. So to avoid this issue again. I thought I would post it here.

First mistake I made was to just open the command prompt and run stsadm  - you should run it as administrator.  As in, right click it and Run as Administrator.

syntax for the command is

stsadm -o backup
-directory <UNC path or local drive>
-backupmethod <full or differential>
[-item] <created path from tree>
[-percentage] <integer between 1 and 100>
[-backupthreads] <integer between 1 and 10>

full list here
The command I used was

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o backup -directory c:\backup - backupmethod full -force

This started off nicely but it keep givving errors - most notable was this

SqlException: Cannot open backup device 'C:\Backups\Moss\Manual\201008031220\spbr0000\000000C9.bak'. Operating system error 3(failed to retrieve text for this error. Reason: 15105).

BACKUP DATABASE is terminating abnormally.

Yes - does not really tell you anything. 

Long story short - to get it working all I had to do was to specify a unc -directory

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN>stsadm -o backup -directory \\servername\sharename - backupmethod full -force

Somtimes there is a simple answer...

Getting rid fo the RDS Connection Warning

When connecting to a published Application or Remote Desktop through the Remote Desktop Web Access you get a security warning.  This is great to let you know you are about to connect to another machine but you might not want to see it over and over again if you trust the connection.

To get rid of this warning you need to change a few minor details.

When logging into the Web Access site you need to change the default "This is Public Computer" to "This is a Private Computer"

Now when you launch and application you still get the warning message but now you have an additional check box for: "Don't Ask me again for remote connections from this publisher"

That's it not too difficult.

So how about changing this to be the defaults instead of manually having to change the radio button every time a user logs in. We can by changing the login.aspx page.   The location of this file is c:\Windows\Web\RDWeb\Pages\en-US

You can edit the file in any tool you choose really.  I used SharePoint Designer since I had it installed.

You need to edit the following lines:
<input id="rdoPblc" type="radio" name="MachineType" value="public" class="rdo" onclick="onClickSecurity()" checked="checked" />

needs to be changed to
<input id="rdoPblc" type="radio" name="MachineType" value="public" class="rdo" onclick="onClickSecurity()" />

and then
<input id="rdoPrvt" type="radio" name="MachineType" value="private" class="rdo" onclick="onClickSecurity()" />

needs to be changed to
<input id="rdoPrvt" type="radio" name="MachineType" value="private" class="rdo" onclick="onClickSecurity()" checked="checked" />

This will now mean that the default will be the Private Computer option.

This will now also display that horrible red warning message.  If you want to change that message edit the
text behind  const string L_PrivateWarningLabel_Text =

and to change the colour form red to something a little less annoying change the .wrng style in tswa.css

So new when I connect to my login page it looks like this

For more info on how to change the Web access pages check out http://fixmyitsystem.blogspot.com/2010/08/changing-remote-desktop-web-access-text.html

There is another method to avoid the warnings described in this article:
To me it does not really sound like a robust and sustainble method for doing a relatively simple thing.