Provisior, one of the products we develop here at ITQ, has two components: an intranet website and a Windows service. We use the Windows service for long-running processes that you typically do not want to run inside a web server.

The Windows service is installed the first time you start the website. When it’s installed, we add a dependency to the NetLogon service. This prevents the Provisior service from starting before the NetLogon service. We did this because our service attempts to access a SQL Server database right when it starts using integrated authentication. This fails when the NetLogon service has not started yet.

All of this works fine when the machine that runs Provisior is joined to a domain. However, when that is not the case, the NetLogon service doesn’t run. You can start it, but it stops again immediately with the following error in the event log (at least on my machine):

“This computer is configured as a member of a workgroup, not as a member of a domain. The Netlogon service does not need to run in this configuration.”

So now I have a Windows service with a dependency on NetLogon that doesn’t run. How to fix this? Apparently, removing service dependencies is only possible from the Windows registry. You need to go to the following registry entry: HKLM\SYSTEM\CurrentControlSet\services\<service>. There you find a REG_MULTI_SZ key named DependOnService where you can remove any services your service depends on. After doing so I had to reboot my machine because the service control manager did not see my update.

I could have updated Provisior to install the NetLogon dependency only when the machine is joined to the domain (here is some info on detecting whether your machine is joined to a domain). However, Provisior is hardly ever run on a machine that is not joined to a domain. This only happens in testing scenario’s so I’d be changing code just for this very specific case.

Ik ben op 14 juni op het IT Asset Management Congres van Heliview met een goede businesscase voor Provisior i.c.m. een software asset management tool. De voorbereidingen zijn in volle gang dus volg ook http://itam.heliview.nl/

In the latest version of Internet Explorer users now have the option to pin a tab to the taskbar. It works like a favorite, but just one click away instead of having to open the browser first.

Pinning a tab is a nice feature, but they didn’t stop there, these pinned pages can also supply custom jumplists to make access to common tasks even friendlier.

To demonstrate this feature I added a jumplist to our own product Provisior

Provisior uses a MasterPage to define the overall layout of the site. This is where the custom jumplist lives as well.

This is what a jumplist item looks like in the HTML source:

<meta name="msapplication-task" content="name=Mijn Info;action-uri=http://localhost/Celerior.Annapurna.UI/MyInfo.aspx;icon-uri=http://localhost/Celerior.Annapurna.UI/App_Themes/Light/Icon/myinfo.ico" />

Just another meta in the page head section, easy enough. But what about dynamic jumplist items? Here’s how I take care of that:

In the MasterPage codebehind I created a simple method that adds a new <meta /> to the page header. Note that the head section in the aspx needs to have the runat=”server” attribute set to programmatically manipulate the header.

private void addMeta(string name, string content)

        {

            var m = new HtmlMeta();

            m.Name = name;

            m.Content = content;

            Page.Header.Controls.Add(m);

        }

To add the jumplist item I can now write the following in the MasterPage Page_Load event:

addMeta("msapplication-task", "name=Mijn Info;action-uri=" + webHost + "/MyInfo.aspx;icon-uri=" + iconPath + "myinfo.ico");

The code above outputs the <meta /> in the first codesnippet.

In the Page_Load you can now write anything you want about when the jumplist items are shown.

There are some other tricks you can do like set the name of the jumplist and the size of the browser window when the site is launched from the taskbar:

<meta name="application-name" content="Provisior" />

<meta name="msapplication-window" content="width=1024;height=768" />

There is also a way to do all this in Javascript but I’ll let you discover that on your own (Here is a good start )

To see some of these jumplists in action, try pinning Twitter or Facebook to your taskbar and right-clicking the icons.

Have fun!

Zie ook: Magazine Centric

Some people asked me after my previous post, how we could move Provisior into the cloud. As some of you may (or may not) know, Provisior is a user provisioning portal that uses Microsoft Active Directory (AD) extensively. This AD is usually a very valuable organizational asset that lives inside a DMZ behind a number of firewalls. This forces us to also install Provisior inside the DMZ. Provisior as a cloud-based service seems impossible.

However, Bob Muglia announced two new Windows Azure features in the PDC 2010 keynote that may make this possible: Windows Azure Virtual Machine Worker Role and Windows Azure Virtual Network (the links actually take you right to the announcements inside the keynote, pretty cool).

With the VM Worker Role it will become possible to migrate completely configured Windows Server 2008 R2 into the cloud. You can run any application you like inside this VM.

Virtual Network is the umbrella name for all Windows Azure networking functionality. One of its features will be the possibility to join a cloud-based VM directly to a customer domain. Perhaps now you can see where we’re going…

The picture below gives a general overview of the idea. Provisior will become a cloud-based web application running inside Azure Web Role. There can of course be different skins for different customers, some customers may have specific functionality enabled but every customer essentially connects to the same application. For every customer a VM is configured inside Windows Azure that joins the customer Active Directory domain. The picture shows three VM’s that correspond to three customer domains. Code running inside each VM uses a sufficiently privileged domain account to be able to access the customer AD.

There are of course some challenges to be resolved:

• How do we make sure that every user request is directed to the correct VM?
• How do we authenticate users? Currently, Provisior uses Windows authentication. Can we still use this somehow, given that users from different domains access the same cloud application. I haven’t looked into that yet.
• And a more practical question: how difficult is it to transform Provisior into a cloud application?

When the CTP for Windows Azure Virtual Network is released, I’ll surely take a look to see what is possible.

 EDIT: If you want to know more about Windows Azure Virtual Network, there is a pre-recorded PDC session that goes into the details: http://player.microsoftpdc.com/Session/3a93d6a3-e52e-4613-b18b-a49754203d09.