When submitting a product for Windows Logo certification one is required to digitally sign and submit a file (winqual.exe) to the winqual.microsoft.com web site.  In order to sign the file you first need a VeriSign organisation certificate that, presumably, is designed to verify you are from the company you purport to be from.  Fair enough.

The VeriSign process is relatively straight forward:

1. Go to their web site and purchase the certificate
2. They send you an email with a URL and a PIN
3. You go to the web site and “Install Certificate” direct from the web page

It’s in step 3 where it all went horribly wrong for me.  Stupidly, I am not using IE7.  After several lengthy discussions with VeriSign “chat consultants” I was told in no uncertain terms that IE7 was the only supported browser and that to get my certificate I had to “find a machine with IE7 on it”.  Then I could simply export the certificate and move it later.

I had used IE8 on Windows 7 x64 to make the order, and it turns out that even if you do find a IE7 machine it still won’t work because it has to be the same machine you placed the order on.  I confirmed, that Firefox, Chrome and Safari also will not work.

Diagnosis

Faced with basically no way forward I decided to fix the problem for them.  I had noticed that my IE8 was throwing script errors so I pulled up the source and noticed that VeriSign are using VBScript to write an object tag, which loads a COM dll of their making, which in turn records the public key in Windows’ certificate store.

My first attempt was to take the VBScript code and make a “vbs” file out of it but that really seemed like it was a bit harder than it should have to be.

The Fix

On my second attempt I simply marked the VeriSign web site as “Trusted” and the “Install Certificate” button on the page worked like a charm.

VeriSign FAIL!

So, OK this port could have been shorter, but now you know. Make VerSign’s web site trusted before (or during) the process to get the certificate installed. Don’t bother asking VeriSign for help.  They can’t.

Making a web site trusted in IE8

Tools –> Internet Options –> Security tab –> Trusted sites –> Sites button –> Type https://*.verisign.com and click Add

Now you know.

After a very thorough investigation, especially after we looked into the App_Browsers.dll assembly through a reflection tool, we found out that the publishing process altered the controltype attribute in the .browser files from this:

System.Web.UI.WebControls.Menu, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

to this:

System.Web.UI.WebControls.Menu, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

It seems that App_Browser.dll file generator of VS 2010 is making a bad assumption even though the target framework is set to .Net 3.5. Because the web application is set to run on 2.0 framework, those control type is not matched.

Fortunately, we’ve figured a work around which is by deleting the App_Browser.dll and the related .compiled file out of the bin directory after publishing, and copy the uncompiled .browser files back into the App_Browsers directory.

Unfortunately SurveyGizmo use a JavaScript function “$” that is an internal system function.  The astute amongst you have noticed the “$” function is used by many other JS frameworks, notably jQuery, becoming increasingly popular and soon to be embedded in Visual Studio 2010 (or so I am led to believe).

The upshot is that all your jQuery defined after your survey is embedded on the page will break.  That’s bad.

I was advised by SG support to use the jQuery.noConflict() function, which makes SG work properly (that’s good) but it also means all your jQuery now uses a function called “jQuery” in place of “$” (that’s bad… again).

We devised a workaround that lets everybody play nice and it seems to work for us so far – thusly:

Immediately before the SG injection script add the following:

<script> var JQ$ = $; </script>

Add SG injection script as normal

Immediately after the SG injection script add the following:

<script> $ = JQ$; </script>

Basically we keep a copy of the jQuery “$” function in a variable and restore it to its original value when the SG scripts have finished.  I do this rather than using “var $ = function( selector, context ) { return new jQuery.fn.init( selector, context ); }” because jQuery may change their initialisation parameters at a later date and I prefer to not have to update my code.

I went looking to pull the photos off my iPhone this morning only to discover that it wasn’t showing up in Windows Explorer as a device anymore.  Quite certain it worked at one point but what can you do.

The drivers that make the iPhone appear as a USB device are usbaapl.sys and usbaaplrc.dll.  If your installing you should look for usbaapl.inf which is in C:\Program Files\Common Files\Apple\Mobile Device Support\Drivers. More about this later.

Connect your iPhone by USB, then open Windows Device Manager (right-click My Computer and select Manage). You may find your iPhone under “Universal Serial Bus Controllers”, where mine was, or possibly under “Portable Devices”.  At any rate if your phone can sync with iTunes it will be in there somewhere.  It should be called Apple Mobile Device USB Driver or something like that. When you find it, right-click and select “Uninstall” but don’t remove the files from the PC.  There’s nothing wrong with the files (probably) it’s just the device registration that has become cactus.

Once uninstalled disconnect the device and reconnect again.  After a minute you should see the device registered correctly, iTunes fires up and Windows Explorer shows your iPhone as a camera again.  Job done.

My driver files were already in Windows\System32 directory cause that’s where drivers go, but the original files that ship from Apple can usually be found at C:\Program Files\Common Files\Apple\Mobile Device Support.  If you deleted the files in the uninstall step when you shouldn’t have you can likely find them there, otherwise I would re-install iTunes cause I would guess they ship with the iTunes software though I can’t confirm that.

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?)

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.

• 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.]

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.

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.

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.