Like any good technophile I picked up a new iPhone 3G on Friday the 11^th and the very first thing I did when getting back to the office was to try to get my Exchange Server to do Direct Push. I have had some small frustrations from the wide distribution of documentation on the subject so hopefully this post will save someone some time.

For the sake of simplicity this article will deal with the simple case of:

• Stand alone Exchange, i.e. not a front-end/back-end setup
• No proxy server, e.g. ISA
• Single firewall

Frankly if your setup is more complicated than that you probably already know how to do this and aren’t reading this anyway. Moving right along…

This is what you’ll need before you get started:

• An iPhone 3G (it doesn’t work on the v1 phone)
• Exchange Server 2003 SP2 or later
• Access to your firewall/router
• A fixed IP address on the internet
• Access to your domain settings
• A valid SSL certificate on your Exchange server – get one, they’re not that expensive
  • http://www.completessl.com from USD$49
  • http://www.instantssl.com from USD$65
  • http://www.trustico.com.au from AUD$20

Background

Direct Push works because the internet is slow. That’s the headline.

Basically the iPhone will make an HTTPS connection to your Exchange Server’s “Microsoft-Server-ActiveSync” virtual folder (most likely on the default web site). It will hold each connection open as long as possible, or until some pre-configured timeouts occur. Should you receive an email during this open connection, Exchange will send notification down to the iPhone which will tell you that you have new mail. Simple as that. The reason it works is because the internet protocols were designed to not receive an instant response from the server when making a request (see “slow” above). Direct Push takes advantage of this extended open connection.

To prevent your battery from draining in 25 minutes flat the chatter on the connection is kept to a minimum. It’s very clever.

Before You Start

If you have a Wi-Fi connection active on the phone it won’t work. Direct Push only works over the air (the 3G connection). This is because the Wi-Fi radio will kill your battery. With Wi-Fi enabled I believe the phone reverts to a pull model, based on observation, but I can’t confirm that.

Setup

Is your iPhone’s Wi-Fi off?

Step 1. Router/Firewall Setup

• Go to the “Port forwarding” or “Services” setup
• Open port 443 on TCP to enable the HTTPS communication – do not be tempted to do this using HTTP. It’s possible, but don’t do it. You have been warned.
• Make sure the endpoint is your Exchange server’s internal IP address
• Restart the router/firewall

Step 2. Domain Name Setup

• Add a new host to your internet domain called “exchange” and point it to your router’s fixed internet IP address – not absolutely necessary but it makes everything a bit clearer if you ask me.

Step 3. Exchange 2003 SP2 Setup

• Open Exchange System Manager
• Expand “Global Settings”
• Right-click “Mobile Services” and select “Properties”
• There are several options required to support older technologies but the ones you want right at the moment are as follows:
  • Enable user initiated synchronisation – get the whole thing started
  • Enable Direct Push over HTTP(S) – the bit we want
• Optionally configure Device Security – I recommend it cause then if you lose the thing you can do a “remote wipe”. These are the settings I like:
  • Enforce password on device – makes you enter a PIN to get into the iPhone which is a bit of a pain but worth it for the security. Do you want anyone who finds your phone to have access to all your email and contacts? Cause that’s what will happen.
  • Wipe device after failed attempts – this means if you get the password wrong enough times the phone will wipe itself. Set this number as low as you dare.
  • Refresh settings on the device – set this to 24 to ensure the security policy is checked for updates daily

Step 4. Configure Your Users

• Open Active Directory Users and Computers on the Exchange server
• Right-click the user to configure and select “Exchange Tasks”
• Select “Configure Exchange Features” from the task list
• Under “Mobile Services” ensure that “User Initiated Synchronisation” and “Up-to-date Notifications” are set to Enabled – the Enable and Disable buttons are cleverly hidden at the bottom of the Features grid

Step 5. Configure IIS

• On the Exchange server open up Internet Information Services Manager
• Locate the web site containing the virtual folder named “Microsoft-Server-ActiveSync”
• Right-click the web site in the left pane tree and select “Properties”
• On the “Web Site” tab enter 443 in the “SSL port” – note this may cause a problem if you already have an SSL site on the server
• On the “Directory Security” tab setup your SSL certificate – setting this up is beyond the scope of this article but very straight forward. Google it. Remember: if you have been following along the server will be named exchange.mydomain.com and not www.mydomain.com. Make sure your SSL certificate has the correct name.

Step 6. Test Your Server Setup

• Open a web browser and point it to https://exchange/OMA where “exchange” is the name of your Exchange server (mine is called exchange)
• You might get a certificate error, that will be because the server name on the certificate does not match the server name – that’s OK when connecting to the server from the inside – just continue
• Enter your network credentials (i.e. login) in the form DOMAIN\username for the “User name” field
• You will probably get a warning page saying the device type is not supported, just click OK
• If you’ve got it right you will see a text version of your mailbox – if not see Troubleshooting below

Step 7. Setup your iPhone

• Turn Off Wi-Fi
  
• Tap “Settings”, “Mail, Contacts, Calendars”
• Under “Accounts” tap “Add Account…”
• Tap “Exchange”
• Enter your email address, username (in the form DOMAIN\username) and password
• Ensure SSL is on
• Set the “Server” field to exchange.mydomain.com (substitute mydomain for whatever your domain name is, obviously)

That’s it – should be up and running now. Send yourself an email and see.

Troubleshooting

In my brief time setting this up here are the places where you might come unstuck:

• Router/firewall – make sure the you have 443 pointed at your exchange server
• Exchange test failed? It did for me! – I got a bunch of errors the first time I ran the Exchange test. To resolve them check the following:
  • The ASP.Net version on the OMA virtual folder is set to 1.1.4322 (the Microsoft-Server-ActiveSync can stay at 2.0.50727)
  • The App Pool account (normally Network Service) has read/execute privilege on the appropriate Exchange folders (e.g. “C:\Program Files\Exchsrvr\OMA\Browse”)
  • The App Pool account has read/write privilege on BOTH ASP.Net framework versions temp folders (i.e. “C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files” and “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files” )
• DNS name – make sure you have allowed sufficient time for the new name “exchange” to have fully delegated. This can take 24 hrs.
• Firewall problems – Some firewalls have an idle connection timeout that will need to be increased to at least 15 minutes (by Microsoft’s recommendations). This means that your firewall is disconnecting you – check your documentation or, as always, Google

Helpful Links

Some of the pages that helped me:

Microsoft - Enterprise firewall configuration for Exchange ActiveSync Direct Push Technology

Exchange Team Blog – Direct Push is just a heartbeat away

Brian M Posey (Exchange MVP) – Microsoft Exchange Direct Push Technology (seems to be broken)

Apple’s less that complete instructions (don’t worry, it’s Apple, it just works! Right?)

With the release of Dynamics CRM 4.0 Microsoft has significantly changed their licensing model. The following information is a summary of the new facets as we currently understand them.

Server Licenses

There are 3 flavours of Dynamics CRM 4.0 server as follows:

• Workgroup Edition – This version is limited to 5 licensed users and is designed to be installed on Small Business Server. There is no multi-tenancy (multiple organization) support in this edition.
• Professional Edition – This version is for single organization deployments (i.e. no multi-tenancy) but has unlimited users.
• Enterprise Edition – This version includes the multi-tenancy support as well as some features that allow Dynamics CRM to scale better in large deployments such as role-based services and multiple-server instances.

Client Access Licenses (CAL)

The CAL situation has become somewhat more complicated with CRM 4.0. Not only are there the normal variations for per-Device and per-User but there are now 3 flavours of CAL:

• CAL – With no decoration to the name, this is the normal read-write client license required by all users of the system who wish to read and write data.
• Limited CAL – The “limited” here is meant to imply “read-only”. Whereas in CRM 3.0 read-only users did not require a license, a “limited” CAL is now required. Note that this is in contravention to the statements in Microsoft’s own Dynamics CRM 4.0 Planning Guide which clearly states that a read-only client does not consume a CAL (don’t believe everything you read).
• Full-use CAL – Despite the tricky name this is not what you might expect, a normal read-write license, but in fact is an upgrade to a Limited CAL for use when a read-only user needs to write as well.

Careful observation will reveal that a regular CAL is the same price as a Limited CAL + a Full-User CAL, so there is no penalty for starting with a read-only license and migrating to a read-write license at a later time.

External Connector Licenses

Dynamics CRM 3.0 had 2 licensed elements: server and client, but Dynamics CRM 4.0 includes a new element – the external connector. An External Connector is needed when a number of users are going to connect to the CRM system to read or write data by way of another system. 5 Limes is often called upon to created SharePoint widgets and web pages that extract data from or deposit data into Dynamics CRM. In CRM 3.0 we would have used a single CAL to achieve this, but in 4.0 an External Connector license is required. At the time of writing the a read-write External Connector license is roughly 5 times the price of a single read-write CAL and the read-only External Connector is roughly 6.6 times the price of a single read-only CAL. So if you have 5 external users or fewer you are better off licensing them individually, but if you want to connect Dynamics CRM 4.0 to your web site you will need the External Connector.

Server & CAL Packs

There is an option to buy Professional Server and 5 CALs at the same time, but there is really no difference in the price compared with buying them separately (at least there is negligible difference in the RRP).

A note on Action Pack Subscriptions

The version of Dynamics CRM that is made available through the Microsoft Action Pack is the Workgroup Edition. This edition is limited to 5 named users. In CRM 3.0 it was possible to purchase additional CALs when more users needed to access the system but in CRM 4.0 that is no longer possible. So if you are planning to deploy Workgroup Edition (through an Action Pack or otherwise) you should be aware that your 6^th user is going to be expensive.

A few pieces of interesting information regarding Microsoft Dynamics licensing that we have recently discovered:

• If you have licensed Dynamics CRM 3.0 as part of an Action Pack subscription it is not possible to add more than 10 active users. This is because since the release of CRM 4.0 the FPP (or full packaged product) CAL that was required is no longer available and it is the only kind of CAL that came with a key. No key means no additional licenses.
• If you have licensed Dynamics CRM 4.0 as part of an Action Pack subscription be warned you are only entitled to the “Workgroup” edition which has but 5 users. This cannot be extended.

Interestingly since Microsoft deems the “Action Pack” to be a subscription-based license you, as the client, do not actually “own” the license and therefore are not eligible for upgrade pricing either. When you hit the 6^th/10^th user (depending on your version) you will be up for the CRM Server license and as many CALs as you have users, since you cannot use the Action Pack CALs on a box product or volume license. This obviously makes the transition very expensive and while you can at least continue to use your Action Pack SQL Server it seems like this group have not been well catered to in the revised licensing model.

By the way – Action Pack users are generally Microsoft partners – not the group I would have chosen to upset, but then they have more money than me…

[UPDATE - With the recently released Microsoft CRM 4.0 there is all new confusion.  See my new post on Microsoft Dynamics CRM 4.0 Licensing for more info.]

We use Microsoft Office SharePoint 2007 internally to manage all kinds of work and share documents. It’s a very effective tool. We also use it to manage our software registration database.

To facilitate customer software registrations we have a public-facing web service that uses SharePoint APIs to communicate with our registration site. The configuration of SharePoint required some fiddling to make this work. The problem was that we had SharePoint configured with no anonymous access, and obviously the users of our software that would be registering would not have credentials for our network – we didn’t really want to enable anonymous access so a creative solution was required.

In order to achieve this we used the web.config <identity /> element in our public-facing website to set the identity of the thread to a fixed user account created just for the task. The web service application pool is configured in IIS to run as “Network Service”. The SharePoint API seemed to pick up the user from the HttpContext.Current.User object, rather than from the thread which means that all our communications were failing with 401.5 errors. I was a little surprised to discover that despite the <identity userName=“user” password=“pass” impersonate=“true” /> in the web.config file, the HttpContext.Current.User was still anonymous.

The two tricks that made it work were:

• In Global.asax use the Application_BeginRequest() method as follows:
  HttpContext.Current.User = new WindowsPrincipal( WindowsIdentity.GetCurrent() );
  
• In our code ensure that each time we made a connection to the SPWeb we called:
  spWeb.AllowUnsafeUpdates = true;

The Global.asax trick ensures that the context carries the same user account as the impersonated thread.

The AllowUnsafeUpdates is required when impersonating.

I was just working on a Windows app that contains lots and lots of User Controls all of which inherit from a base User Control.

When I opened the controls they displayed blank in the designer. After some digging I realised that two vital pieces were missing:

1. All controls need to have a parameterless constructor, but they do not need to be public (mine are “protected”)
2. The default constructor needs to call InitializeComponent() as this is the method that puts controls into their positions on the form

It seems the Forms Designer creates an instance of the control by calling the parameterless constructor (which seems obvious when you think about it I suppose).

The giveaway on the InitializeComponent() call was the comment just above the call injected by default which reads “Required for Windows Form Designer support“.

Anyways – hopefully this will save somebody some time.

Recently I was deploying a web site with Flash video on. The Flash SWF files and associated FLV files (these are the ones containing the video that is streamed back to the user) were all in the correct directories however the videos still would not play. Instead I simply saw a blank screen.

Windows IIS only serves files for which a MIME type is configured. There are several levels you can configure these including for the whole server (right-click server > Properties > MIME types) for a particular site (right-click site > Properties > HTTP Headers > MIME Types) or even for a folder beneath the site. You will notice that the settings are inherited, so specifying the value for the server negates the need to specify it for each site, and so on.

Set the MIME type as follows:

Extension: .flv

MIME Type: video/x-flv (other MIME type settings may also work)

If you altered the MIME setting on the server you will need to restart with “iis_reset” but if you only altered the setting for a given site then simply stopping and starting that site is enough.

If you’re like me you will have a development machine that’s got a bit of power behind it. You might also be a bit keen on new technology. You may have even gone ahead and installed Windows Vista thinking – she’ll be right.

If you’re still like me at this point you’ll be thinking “bugger”.

Visual Studio.NET 2003 is not supported on Vista = but it does work for the most part. The big issue is web development.

What has worked for me, and may well work for you, is installing Windows XP on Virtual PC 2007 (free). I put my web sites on the XP VPC and I can still run the IDE on Vista. While this is a little clunky everything seems to work pretty well.

Then one day… bang! The debugger refused to attach.

Checking the event logs I found a very unhelpful Event ID 10023:

“The application-specific access security descriptor for the COM Server application C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe is invalid. It contains Access Control Entries with permissions that are invalid. The requested action was therefore not performed. The application set this security permission programmatically; to modify this security permission contact the application vendor.”

I have no idea what happened from one minute to the next but it was properly busted. I tried a million things including every known remote debugging setup check. I even reinstalled VS.NET 2003 & VS2005. The thing that eventually did the trick was:

• Stop the “Machine Debug Manager” service
• Start > Run > “C:\Program Files\Common Files\Microsoft Shared\VS7Debug\mdm.exe” /regserver
• Restart the service

I suspect there was another issue, and in trying to solve it I had added domain accounts to the DCOM config of Machine Debug Manager in “Access Permissions”. Further testing has revealed that this is what has killed it. If you are having this problem now you know why For some reason simply removing the offending accounts doesn’t help you have to perform the steps above.

The number one problem I find when I help someone debug a problem is the assumptions that have been made.

If you’re running a program and it doesn’t behave the way you expect it to what are you going to do? “Step through the code to see what’s going wrong” you say? Chances are that will only help you if you’ve done something obvious, like a typo or a missing bracket. Besides which there are lots of times when stepping through code is impractical or just not possible, such as when the problem is in a CSS style expression. Debugging these is a downright pain.

The first thing you should do after the obvious leads are exhausted is to CHALLENGE YOUR ASSUMPTIONS! (Yes I’m shouting it.)

I can’t stress this enough – back to the aforementioned CSS style, what kind of assumptions have we made:

• Did we get the class name right?
• Is there another class in another stylesheet with the same name?
• What order are the stylesheets loaded?
• Are we even editing the right file?

Simple questions to answer but do ask them. A lot of the time you’ll notice that you aren’t where you think you are – which explains why you’re going the wrong way.

Get used to using Debug.Assert()

If you don’t use this gem of a method you’re only slowing yourself down. This comes right back to challenging your assumptions. The Assert() method allows you to add a test expression and a message into your code – when the test fails the message is displayed. The beautiful thing is you can leave them all over the place, because when you compile for Release the compiler leaves them all out.

You should include one of these whenever you make an assumption in code – because we can’t always remember our own rules, and sometimes we’re not the only ones using our code. For example, I recently had a problem with a form’s progress meter not displaying properly – I never got any value from it. I added a Debug.Asset() to check the value of pb.Maximum – surely the maximum value was not set to 0 – it should be the record count from a record set I had just loaded. Oh no… turns out the call to set the maximum and the call to load the records were in the wrong order. The Assert pulled me right up. This gets even better when you’re programming in a multi-threaded environment, because the act of debugging interferes with the way the threads behave, since you artificially slow down the execution.

Debugger.Launch() & Debugger.Break()

Two more little gems, these. Quite often people ask on news groups and the like “how do I debug a Windows Process”? EASY!

In your Start() method simply add:

Debugger.Launch();

Debugger.Break();

When the run-time hits the first line it will pause processing and prompt you to attach a debugger. The second line is a programmatic break point (which you don’t officially need but the Launch() breaks you into the Dissassembler instead of the code).

If you’re a web programmer you may already know about…

Javascript: debugger

This works the same way as Debugger.Launch() but for Javascript – perfect for debugging web pages! It is a statement, not a method, so to use it simply put in the line:

debugger;

and you’re done.

Welcome to the 5 Limes blog site.

We work with some of Microsoft’s finest technology - and it never ceases to amaze us at how many tricks we pick up along the way. In our blog we will share with you some of the things that we discover on our journey. Hopefully these will help you get out of trouble one day, and you can be wise rather than smart.

Until next time…