Microsoft Exchange and Blackberry Server Specialists

SEMblog

Microsoft Exchange Server and
Blackberry Enterprise Server news, views and fixes.

First Windows Mobile Emulator Image with AKU 2.0

If you have looked at my technical web site, amset.info recently, I have an article on using the Windows Mobile 5.0 emulator to ease support of Windows Mobile devices. (http://www.amset.info/pocketpc/wm5emulator.asp)
Unfortunately the emulator images aren't keeping up to date with the Windows Mobile released versions, and as such there isn't one with the latest MSFP update.

However Microsoft have recently released the first emulator image with the AKU 2.0 update, which you can download from here: 

http://www.microsoft.com/downloads/details.aspx?FamilyId=EB580A44-CB40-4BE1-9FF3-E224BF669CD0&displaylang=en

When you install the download it claims to require the SDK and Visual Studio, but it doesn't actually check for these, so you can install if you don't have either installed.

The files install to the following location by default:
C:\Program Files\Windows CE Tools\wce500\Emulator Image for Windows Mobile 5.0 Smartphone 320x240 (Landscape)

All is not what it seems.

The download file does not contain a dess file, but an nb0 file, making its use a little more complex. It is also a Smartphone image, not a Pocket PC image, which limits your options somewhat.

However if you would like a look, you need to use a complex command line string to start the image. As it is a Smartphone image you need to use the supplied skin so that you can actually control the device.
Also note that the skin doesn't have numeric keypad, but you can use the numbers on your keyboard to enter those.

Here is the command line I have been using:

"C:\Program Files\Microsoft\Device Emulator Preview\DeviceEmulator.exe" "C:\Program Files\Windows CE Tools\wce500\Emulator Image for Windows Mobile 5.0 Smartphone 320x240 (Landscape)\Deviceemulation\0409\SP_USA_QVGA_LANDSCAPE.nb0" /skin "C:\Program Files\Windows CE Tools\wce500\Emulator Image for Windows Mobile 5.0 Smartphone 320x240 (Landscape)\Skin\Smartphone_Landscape_QVGA.xml" /n /tooltips OFF /memsize 256 /s "C:\Program Files\Microsoft\Device Emulator Preview\smartphoneaku2.dess"

Not pretty.

If I tear it down to remove the paths, it is actually:

DeviceEmulator.exe SP_USA_QVGA_LANDSCAPE.nb0" /skin Smartphone_Landscape_QVGA.xml /n /tooltips OFF /memsize 64 /s smartphoneaku2.dess

where

DeviceEmulator.exe would be the full path to the device emulator

SP_USA_QVGA_LANDSCAPE.nb0 is the nb0 file from the download

/skin Smartphone_Landscape_QVGA.xml is the Smartphone skin that is also in the download

/tooltips OFF turns off the tool tips

/memsize 64 is the size of the RAM in mb.

/s smartphoneaku2.dess is the name of the file to save the machine to once you have started it once.

You should be able to develop your own path based on your install locations. Once you have run it once - then you can simply save the machine and restore the file using the Device Emulator Manager.

SSL Certificates
The device is locked, so importing an SSL certificate is a little more complex. That will have to wait for another blog post.

New Articles on amset.info #2

I have added some new content on OWA...

Redirecting OWA... How you have can have a single URL for both OWA and OMA then redirect accordingly.
Or have a plain http URL on your web site for the users to remember that redirects them to a secure site - means you don't have to open port 80 to your production network.
http://www.amset.info/exchange/owa-redirectpages.asp

OWA URLS
By manipulating the URLs in OWA you can display the information in different ways.
http://www.amset.info/exchange/owa-urls.asp

Stop Exchange using a Script
I have posted the script file I use when I need to stop Exchange.
http://www.amset.info/exchange/shutdown-script.asp

Coming Soon...
As I seem to be helping with a lot of EAS and OMA queries at the moment so I am currently working on a series of articles on Exchange Active Sync, Outlook Mobile Access. Look for those real soon.

First to Six Million in a single TA at EE

Last week it was speculated in the Experts Exchange Newsletter who would be the first to six million points in a single topic area - me or objects (see here http://blog.sembee.co.uk/archive/2006/03/03/8.aspx).
Overnight (9th - 10th March) I won that little race.
To give you an idea of the level of achievement, my six million points in the Exchange Server Topic Area is more than anyone other than the top five (at the time of writing) experts have on the entire site.
I guess the next target is first to 10 million points overall!

VPN Through a PIX

Stuck out on site with a client, I couldn't connect to home via VPN. The client has a Cisco PIX and a quick bit of research showed that while the PIX will allow PPTP pass-through, it isn't enabled by default.

Apparently you need 6.3 of the PIX software, but then you can add the following command to the configuration and can then use the Windows VPN client:

fixup protocol pptp 1723

A quick change and I was able to connect home.
More information on Cisco's web site
You have to make a similar change if you need to go through a PIX with the Cisco VPN client to connect to a remote Cisco VPN server. In that case the command is:
ISAKMP NAT-TRAVERSAL
Another command that requires version 6.3 of the PIX software.

Why you shouldn't use Self Generated SSL Certificates

A constant theme on many of the Internet forums is the use of self generated SSL certificates versus purchased SSL certificates, particularly when deploying RPC over HTTPS or Outlook Web Access.
Many people will advocate that using a self generated certificate is fine and will do the job.
This could be a certificate generated from the selfssl.exe tool that is supplied with the IIS Resource Kit, or Microsoft's certificate application.
However I am not one of them, and always deploy Exchange with a purchased certificate.

Use of SSL Certificates
SSL Certificates have two main tasks. 

  1. To prove that the server you are accessing is the server that you meant to access.
  2. To encrypt the connection between the application being used to access the server, and the server itself.

There are three things that your web browser looks for when accessing a secure site.

  • that the name on the certificate matches the address being accessed
  • the certificate is issued by someone the browser trusts, or the certificate matches one already installed on the web browser
  • the certificate is valid.

If any of those three fail, then you will get a warning message popup.
With self generated certificates, you will get the warning message when you access the server. This is because the certificate hasn't been issued by a trusted authority.
You can get round that warning message by importing the certificate in to the web browser. However that makes a lot of work with deployment, complicates matters and also means that you have to repeat the exercise when the certificates expires.
It also doesn't help when people are accessing your site from a public computer where you cannot install the certificate, such as an internet café or their machine at home.
And that is where self generated certificates start to cause problems.
You can tell your users to ignore the message when connecting to your site, but users have a habit of only hearing what they want to hear. They will hear "ignore the message" but forget the bit "when using our site". In these days of phishing and spoof web sites network administrators need to give out a consistent message - and telling users to ignore a security warning is a very example of failing to do that.
A security warning of any kind looks unprofessional and shows a lack of concern for security.

So what are the alternatives?
The best alternative is to purchase an SSL certificate.
However many administrators think that they need to go to one of the big SSL certificate issuers such as Verisign and pay US$400 or more per year - and that is just for a 40 bit certificate.
That is not the case.
I do my deployments using RapidSSL certificates. They cost US$69 per year and that is for a 128bit certificate. Their root certificate is in most of the popular web browsers so there is no complication there.
If you do need to deploy the certificates to Pocket PC devices, then that can be easily done (see http://www.amset.info/pocketpc/certificates.asp).
You could also certificates from Certificates for Exchange which are trusted by Windows Mobile 5.0 with MSFP and higher. Nothing to install on the devices making deployment easy.
You may also see some "free" SSL certificates around. These should be looked at carefully, paying particular attention to the root certificate support. If the root certificate isn't in the majority of web browsers then you will have the same problem as when issuing your own certificates - prompts and imports.

Do Self Generated Certificates Have a Place?
Yes they do. I use them all the time in lab environments. When I have control over every item accessing the service, then I will use the a self generated certificate and make all of adjustments as required to get it to work correctly. However in a production deployment, they are never used.