2003 certificates exchange orange spv

Connecting a Windows SmartPhone to Exchange Server Protected with a Private Certification Authority Digital Certificate

Having recently obtained my first Windows Mobile powered SmartPhone, I needed to connect to my Exchange Server over the internet using ActiveSync. For those of you unfamiliar with Windows Mobile SmartPhones, they let you connect, using the phones internet connection (typically over a GPRS network), to your Exchange 2003 Servers to download your email at a given schedule. Additionally the SmartPhones running Windows Mobile 2003 and later support “Up-to-date Notifications”, where the emails are synchronised to your phone automatically upon arrival at the Exchange Server independent of the schedule. It was this Up-to-date Notifications feature that I wanted to implement, but it was not as straight forward as I thought it would be when I got down to it!

The reason was the phone. I have an Orange SPV C550 which is locked by Orange, the network operator. This means that you cannot install any software on the phone including any digital certificate that you need to connect to your Exchange Server.

To configure across the mobile network synchronisation of your e-mail you need to have Exchange ActiveSync enabled on your Exchange Server (it is on by default) and ensure that the “/Microsoft-Server-ActiveSync/*” path to an Exchange Server in your organisation is available through your firewall. If you do not use SSL to protect this HTTP session (not recommended) then you need do nothing to your phone apart from configure it to use the server synchronisation to get your email, but if you want to use HTTPS and the certification authority you are using to provide your digital certificates is a private certification authority you will find that you will not be able to connect as your phone will not trust the certificate issuer. Note that in test environments you can use the Disable Certificate Verification tool (see links below) to avoid this issue, but for a production network this is not recommended.

Therefore you need to unlock the phone and install the root certificate from your private certification authority and then relock the phone before you can make a secure connection to your Exchange Server from your Windows Mobile SmartPhone. The last step of locking your phone again is optional, but recommended as it maintains the security of your phone.

To unlock your Orange phone you need to follow these steps, though note that other mobile network operators will either provide unlocked phones or might have an equivalent process:

  1. Make at least one GPRS connection so that your device is registered at Orange
  2. That your handset is switched on and it has a good signal
  3. That you have a record of your IMEI number. You can get this by typing *#06# on the phone.
  4. Visit on a computer (you can do this on the phone, its just easier on a computer). At the time of writing this web page does not list the C550 phone as a phone it unlocks, but it does work.
  5. Choose to “Disable Certificate Security” and click Proceed. Enter the required information and your phone will make an internet connection (which you will be billed for) and it will unlock your phone. Once the phone is unlocked you will see a message in English and French telling you that “Your handset has had its certificate security disabled.”

Once the handset is unlocked you can install any application on the phone that you like, but for the purposes of connecting to your Exchange Server for Up-to-date Notifications:

  1. Start Internet Explorer on your phone and browse to a web site containing your root digital certificate (or use SPAddCert.exe if you already have the certificate downloaded to the phone’s memory. SPAddCert’s download location is on the list of links below). For example if your certificate server is the version that comes with Windows then visit http://servername/certsrv/certcarc.asp and download the certificate.
  2. Confirm that you want to install the certificate at the prompt. Assuming that the phone unlock was successful, the certificate will be installed.
  3. You can now relock your phone using the same process as described above, just choosing the “Enable Certificate Security” option instead. Though whilst your phone is unlocked you might want to investigate Global Contact Access from Microsoft (see the links below) to give your phone more access to your Exchange Server, such as the Global Address List and Free/Busy information.

Configuring Exchange ActiveSync on the Exchange Server is beyond the scope of this article, but full instructions can be found in the Microsoft Press Exchange Server 2003 Resource Kit on pages 892 onward to the end of the chapter.

Once you have the certificate installed you can configure the device to connect to the Exchange Server. This is done by starting the ActiveSync application on your phone and setting the options. Option 3, Server Settings controls this functionality and you need to choose menu item 4 (Connection). Here you need to enter your username, password and domain along with the server name, which is the web address to the Exchange ActiveSync server (for example You can leave the SSL option selected as you now have the ability to do this connection securely, without needing to purchase a digital certificate from a public certification authority.



Start Menu and Multiple Monitors

When you enable multiple monitor on Windows XP, which I did by installing an ATI Radeon card in addition to my existing Nvidia card I found that after changing some of the settings (like which is the primary display), the Start Menu and Task Bar appears on the secondard display. What seemed to happen was the Start Menu etc. moved to one of the display’s managed by the ATI card and then I set the primary display back to the Nvidia card it became the primary display (programs and dialog boxes opened on that display) but the Task Bar did not move back.

Eventually, after much reconfiguration and reseting/rebooting I decided to see if I could drag the Task Bar across. Now this is not supposed to work (maybe it has been added in SP2 for XP). So I unlocked the Task Bar and dragged it first to the side of the current screen (the displays are lined up left to right) and then across to the other display – you cannot drag it straight across the bottom of the displays.

This worked a treat, so I relocked the Task Bar and all works now.


Improving the Performance of IIS 6.0 Applications

Whilst working at a client doing some performance testing of an intranet, web-based, application we came across a little documented way to improve the network performance of the application if the web server is running IIS 6.0 on the Windows Server 2003 platform.

When the IIS 6.0 web server uses Windows Integrated authentication to log users onto a web application it goes through the following process, which is different to how it behaved on IIS 4.0, IIS 5.0 and IIS 5.1 (the versions that run on Windows NT 4.0, Windows 2000 and Windows XP):

  1. Client connects to the web server with an anonymous connection for the first object required.
  2. The web server rejects the connection with a 401 status message, which means that authentication is required.
  3. The client sends the request for the page to the server again, along with the current authentication information. The format of this authentication will differ based on whether NTLM or Kerberos is being used.
  4. Server responds with a 200 status indicating success and the object is transferred from the server to the client.
  5. So far nothing has changed in IIS 6.0 compared to the earlier versions of the software, but now the client makes the request for the second object (maybe a graphic within the page, or a second page on the same server). This second request, even if it is across the same HTTP session as the first, will be seen by the server as an anonymous request and it will be rejected with a 401 status message. In earlier versions of IIS this second (and subsequent requests on the same HTTP connection) were treated as being authenticated because the first object request was successfully authenticated.

This can be seen using the following information from an IIS 6.0 log file that was generated by a web browser making a GET request for four pages called auth1.htm through to auth4.htm.


cs-uri-stem cs-username sc-status sc-bytes cs-bytes
/auth1.htm  -           401       1872     516
/auth1.htm  DOMAIN\user 200       509      2307
/auth2.htm  -           401       1872     557
/auth2.htm  DOMAIN\user 200       510      2348
/auth3.htm  -           401       1872     557
/auth3.htm  DOMAIN\user 200       510      2348
/auth4.htm  -           401       1872     557
/auth4.htm  DOMAIN\user 200       510      2348

The client makes a request for the page auth1.htm. This page is only available to a user via Windows Integrated authentication and so the request is seen as rejected with a 401 status. The second line shows the successful request for the same page and the fact that a Windows domain account was used to authenticate the request. From that point on, each request can be seen first as an authentication failure and then a success. This means additional round trips to the web server, and longer page load times – especially to web servers that are across low latency WAN connections. For example, the above log data shows that the total bytes sent and received by the web server (the sum of the sc-bytes and the cs-bytes columns) is 21065 bytes. We will compare this value to one where the IIS 6.0 server has had performance changes made to it later in this article.

IIS 4.0, IIS 5.0 and IIS 5.1 worked by allowing all subsequent requests for objects over a single HTTP session that had already been authenticated to use the authentication information of the first successful request. With the increase in security that is part of IIS 6.0 this potential security hole has been closed – it might be possible to take over another session and become authenticated with the credentials of that previous session. This security improvement though, as with many security changes, decreases performance by an increases the number of round trips to the server and the bytes transferred on the network. If the risk is considered unlikely within your environment and users connect to the web server from remote locations then you can set the IIS metabase setting AuthPersistSingleRequest to false. This means that the IIS 6.0 web server acts in terms of authentication persistence like an IIS 5.0 web server.

The two metabase keys that need to be set are:

  • NTAuthenticationProviders
  • AuthPersistSingleRequest

NTAuthenticationProviders can be set at the web service or web site level and AuthPersistSingleRequest can be set at the web service, web site, virtual or real directory or at the file level.

To set these two metabase values open a command prompt, change to the \inetpub\adminscripts folder and run each of the following commands:

  1. cscript adsutil.vbs SET w3svc/1/NTAuthenticationProviders “NTLM”
  2. cscript adsutil.vbs SET w3svc/1/AuthPersistSingleRequest FALSE

The “1” in both the above commands will cause the property to be set on the Default Web Site. Change “1” to affect another web site or remove “1/” from the command to affect the entire server.

Once the two commands have been executed enter the following to ensure that they have run correctly:

  1. cscript adsutil.vbs GET w3svc/1/NTAuthenticationProviders
  2. cscript adsutil.vbs GET w3svc/1/AuthPersistSingleRequest

Finally run IISRESET from the command line to restart the web server.

The following data from an IIS 6.0 log file shows the same sequence of GET requests as described above after the NTAuthenticationProviders value has been set to NTLM and the AuthPersistSingleRequest value set to false.


cs-uri-stem cs-username sc-status sc-bytes cs-bytes
/auth1.htm  -           401       2043     622
/auth1.htm  DOMAIN\user 200       259      774
/auth2.htm  DOMAIN\user 200       260      557
/auth3.htm  DOMAIN\user 200       260      557
/auth4.htm  DOMAIN\user 200       260      557

This data can be compared to that above quite easily. First you can see that the number of round trips is just over half the number on an IIS 6.0 server in its default configuration, as only the first request fails with a 401 status message – the subsequent requests now use the authentication of the first request within the session rather than per request authentication. Secondly the total number of bytes required within the HTTP session to download these four objects is 6149 bytes. This is 29% of the bytes transferred under the default IIS 6.0 configuration.

Therefore, if you run web applications that use NTLM authentication and have high latency networks then you can generate significant improvements in page load time at the browser, and at the client I am working at we reduced page load times from their India offices to the USA servers from 18 seconds to less than 10 seconds.


2003 2008 2008 R2 iis SQL

Enabling ASP.NET Session State without Installing IIS

At a client site, I needed to enable within a web cluster the ASP.NET session state service (ASP.NET State Service) and initially this was going to go on one server within the web cluster. The only problem though, as this configuration is easy, was what happens if the one server in the cluster that this is running on is the server that fails!

The solution we decided was to place the service on the SQL Server back-end database. Though this is not clustered (as it is not mission critical), if the database is unavailable then so is the application so why not run the ASP.NET State Service on that machine.

So we changed the web.config file to read:


We went to the SQL Server (which was running Windows Server 2003 and so had the .NET Framework installed), but found that the service did not exist as ASP.NET was not installed.

So we ran the following, which claims to require IIS to be installed, but successfully enabled the ASP.NET State Service:

aspnet_regiis -i (this is in WINDOWS\Microsoft.NET\Framework\version folder

Set “HKEY_LOCAL_MACHINE\SYSTEM \ CurrentControlSet \ Services \ aspnet_state \ Parameters \ AllowRemoteConnection” to 1 on the server in the above step, set the service to Automatic and started it running.

And it all worked fine.


Hotfix Files

When an update to Windows is installed, if that update is a GDR (general distribution release) update, the possibility exists that a hotfix exists for the same files but in an earlier version. This hotfix would have been developed separatly within Microsoft for the specific customer problem that the hotfix fixes, but as it is not part of the service pack/security update cycle it does not have an obvious version number, and so could easily be installed out of sequence. Therefore the, the hotfix files for that GDR are copied to the %windir%\$hf_mig$ folder. This allows migration to the appropriate files if you later install a hotfix or service pack that includes earlier versions of these files. For example, consider the following scenario:

  1. You apply a security update that installs a GDR version of File.dll with a version number of 5.2.3790.1000 and copies a hotfix version of File.dll with a version number of 5.2.3790.1000 to the %windir%\$hf_mig$ folder.
  2. You apply a hotfix that includes a hotfix version of File.dll with a version number of 5.2.3790.0000.

For more click here.

2003 exchange

Exchange 2003 Resource Kit

The Exchange Server 2003 Resource Kit is almost ready for the shops. It should be available by the end of March 2005 and coming soon to the C7 Solutions web site is a book givaway. I have some copies to distribute as I am one of the authors of the book.


Enabling Remote Desktop Remotely

Run the following from a Windows XP or Windows Server 2003 PC:

WMIC /NODE:”client” /USER:”nwtraders\administrator” RDTOGGLE WHERE ServerName=”client” CALL SetAllowTSConnections 1

windows server xp

Two Logins To Install Software

With Windows XP you sometimes see that your Group Policy settings take two reboots or two logins to work. This is because Windows XP operates (by default) in a mode called Fast Logon Optimization. This means that the computer boots and logs in quicker, but it does mean that events that should occur during the computers boot or login will be delayed until the second boot or login.

Examples of events that this effects are software installations via Group Policy and folder redirection (i.e. home folders). During (or usually just after) the first boot/logon XP sets a flag and then during the second boot/logon Windows operates one time only without the Fast Logon enabled.

An example of the two events that appear in the event log (in chronological order) are:

Event Type: Warning
Event Source: Application Management
Event Category: None
Event ID: 108

Event Type: Warning
Event Source: Application Management
Event Category: None
Event ID: 101

This behaviour can be changed by turning the Fast Logon Optimization off. This can be switched on and off via Group Policy and the following setting:

Computer Configuration
Administrative Templates
Always wait for the network at computer startup and logon

More on Fast Logon Optimization can be found in article 305293 at Microsoft Support.

terminal server Terminal Services

Setting Remote Desktop to an Alternate Port

The default port for Remote Desktop is 3389, but there are cases where it is useful to change this port, for example on the external interface of a firewall should you be providing remote support of said firewall. These steps are known to work on Windows XP and Windows Server 2003. They have not been tested by me on other versions of Windows.

On the Remote Desktop Server

    1. Start Registry Editor (Regedt32.exe).
  • Locate the following key in the registry:HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\ TerminalServer\ WinStations\ RDP-Tcp\ PortNumber
  • On the Edit menu, click Modify, click Decimal, type the new port number, and
    then click OK.


  • Quit Registry Editor.



On the Client

    1. Click Start, click All Programs, point to Accessories,
      point to Communications, and then click Remote Desktop Connection.
  • In the Computer box, type the computer name or IP address of the
    computer to which you want to connect, followed by a colon (:) and the port
    number you want to use.For example, to connect to port 3390 on a computer named “MyXPPro,”
    type the following information: MyXPPro:3390

    To connect to port 3391 on a computer with IP address,
    type the following information:


More information at;en-us;306759


Enabling Remote Desktop During Installation

If you are installing a number of servers and you want to ensure that Remote

Desktop is enabled on each then add the following lines to the unattend file

that you are using to build the Windows servers (or XP client)




How to enable remote desktop remotely

Lots of sites on the internet discuss how to enable remote desktop in Windows XP and Windows 2003 Server, but the majority of them require you to have physical access to the computer first. So how do you enable remote desktop when you do not have physical access to the computer. It is all to do with the registry!

    1. Make a network connection to the remote computer to ensure that you have administrative access to the machine (i.e. \\computer\c$). This will prompt for a username and password of the administrator. Enter the correct details.
  • Start the registry editor regedit.exe (and not the older application regedt32.exe if it exists – it does not in later releases of Windows)


  • Choose File, Connect Network Registry


  • Enter the computer name as above.


  • Navigate to HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Terminal Server for the registry settings for the remote computer (take care not to select your own desktop)


  • Double-click fDenyTSConnections.


  • Change the value of this setting to 0 to enable Remote Desktop or 1 to disable it, and click OK.


  • If your remote computer has multiple network cards and you want to ensure that Remote Desktop is operating only on a selected card then navigate to the following registry location: (as above)\WinStations\ RDP-Tcp and note the LanAdapter value. If this is 0 Remote Desktop operates on all networks, and if this is another number then it operates only on the network as identified in the (as first)\lanatable registry key


  • Disconnect the remote computer from the registry editor using File, Disconnect Network Registry, and selecting the correct remote computer in the list.



Note: Subsequent to publishing this I have discovered a much quicker way using Windows management Instrumentation command line (WMIC). See here for more on this.