I asked if there were any technical reasons for this, hoping to hear of some impressive new development that they figured they couldn’t go to market without - but the answer was no, the features list is set. Why the long delay then? There was something about needing more real-world testing, and the need to develop scenario guidelines (I suppose that means walkthroughs), but that was the only explanation.

There is apparently some way you can get a pre-release license from Microsoft if you’re really determined to go ahead with ILM 2 in production, but I expect most organisations will not accept this, putting ILM 2 well and truly off the cards for 2009.

Unfortuantely this has been proving trickier than I would have liked, and the main culprit is the Function Evaluator. This little workflow action is supposed to be able to assign values to attributes in the portal but, as it turns out, is completely broken in RC0.

I struggled for some time with the Ensynch guys’ posts on how to build your own replacement for the Function Evaluator (see here and here) – but, not being much of a programmer, this proved too much for me. I have now found myself a satisfactory workaround using a good old fashioned MIIS approach (and some codeless provisioning rules).

Overview

The approach is simply to add an extra SQL table and MA. Using export flow rules I generate the values I want into the table and then import them back in. I can now flow these values back into the portal through the ILM MA.

So an account creation started from the HR database would go like this:

HR -> ILM -> GenerateAttribtes -> ILM -> AD

The rest of this post is really just an example of how to codelessly provision to the GenerateAttributes SQL MA.

Configuration of the ILM MA

The ILM MA only allows direct classic flow rules, so that’s pretty straight forward.You should create both Import and Export flow rules for all the attributes you’re using.

If you need some extra attributes in the ILM schema then see the Schema UI document.

The GenerateAttributes MA

The table I’m using is a very simple one (my favourite sort) with an ID field to hold the employeeID, and the various other values I want to generate.

This table is linked into ILM using a bog standard SQL MA. I’ve been finding it works better to use classic Import attribute flows, mostly because the precedence works.

And I set that precendence so that the GenerateAttributes values can replace the ILM values.

The HR MA

Continuing as above, I created classic import attribute flows for the HR MA.

I did make one exception and used a sync rule for flowing the StaffID (number) into the employeeID (string). Using a classic Advanced IAF I would have had to write some code , but with the sync rule it is a simple matter of concatenating the number with a blank string. As I’m not provisioning there is nothing else to do here, apart from importing the sync rule object in the MIIS metaverse.

The Provisioning Sync Rule for GenerateAttributes

I then created a sync rule called GenerateAttributes-export-person for provisioning and EAF for the GenerateAttributes MA. I’m please to report this worked first go – I must be getting the hang of it!

I defined a Set which I called “_All Users” and which finds all the people who should have user accounts. It’s pretty much the same as the one in this post.

Next I created a Workflow called “_GenerateAttribute Export SyncRule” which runs the Sync Rule.

And finally I created a Management Policy called “_Provision GenerateAttributes” configured as follows:

• Requesters: “All People”
• Operation: Create resource, Add/Remove/Modify resource attributes
• Target Resource Before/After request: “_All Users”
• Action: “_GenerateAttributes Export Sync Rule”

Generating the Attributes

Now, as soon as a person is created or changed, and as long as they appear in the Set you defined above, you should see this new sync rule added to their Provisioning ERL.

When you run an Import Sync of the ILM MA a new object will be created in the GenerateAttributes MA, complete with the new values.

Export and re-import the values, then export out to ILM, and you now have your generated values.

Finally, Provisioning to AD

I have already blogged about how to codelessly provision AD/Exchange 2007 users here, so I shall refer you to that post.

I will just add that my Workflow for AD provisioning is applied “Based on attribute value”, and the attribute is “Account Status”. I flow a constant value of “Approved” from the HR MA, then I replace that with “Active” from the GenerateAttributes MA. Only when the person is updated with the “Active” value in ILM does the AD provisioning rule get applied.

Workflow

I have changed yesterday’s Workflow a little so that it now uses “Based on attribute value” as the Action selection. This seems to give me more control over where the sync rule is applied.

Synchronization Rule

The following table shows the configuration of my sync rule.

Note that I have used a number of custom attributes to construct the homeMDB. Apart from this being a more flexible approach, I actually got an “unexpected-error” in MIIS when I hard-coded the entire homeMDB string. For the RC0 documentation on modifying the schema see here.

MA Configuration

The configuration of the ILM MA is as I covered yesterday – you just need to make sure you have all the import flow rules in place to get the necessary data into the metaverse – not forgetting the ExpectedRulesList.

The AD MA should not need any classic flow rules, as you’ve configured everything you need in the Sychronization Rule object. You do need to tick “Enable Exchange 2007 provisioning” on the Extensions page.

Exchange Management Tools

And, just like with ILM 2007, you need to have installed the Exchange Management Tools on the ILM server.

Here’s one I prepared earlier

Here’s what a provisioned user looked like just prior to exporting him from the AD MA.

Immediately after exporting I was able to login as this user, open Outlook, and send an email. Hooray!

Another nice surprise: as I had gone through the Password Reset and Registration configuration, and had already installed the ILM client on this workstation, the user was immediately prompted to register for password reset! Now that I do like.

This post goes through the steps I took to provision user accounts into AD. For the extra configuration need to add Exchange 2007 mailboxes to those users accounts see this post.

All the objects you have to create

Synchronization Rule

I will say that I do like the codeless flow rules. All you have to do to get those working is create a Synchronization Rule in the portal, import it into MIIS and you’re away.

To get the Synchronization Rule to also do provisioning you need a few more bits and pieces.

Set

You must create a Set which will contain only those users which will exist in your target directory. (A tip on naming: start it with an underscore “_” so that it appears at the top of the list.)

Don’t do what I did and use “All People” because then it tries to create the Administrator and Built-In Synchronization accounts in your target directory.

Workflow

Next you create a Workflow of type “Action” which has, as its action, the Synchronisation Rule you created above.

Management Policy

Finally you create a Management Policy. I am still a little vague on all the things these objects can do, but in terms of provisioning, this is where you tie your Set and your Workflow together.

ILM MA

You also have to make sure you are flowing your data into the metaverse through the ILM MA, so that it will be there ready to be used by your synchronization rule. For unfathomable reasons the ILM MA still relies wholy on “classic” flow rules.

And now with pictures

Create the Synchronization Rule

In the portal, click on Administration -> Synchronization Rules -> New. The following pictures show how I configured my rule.

When creating your attribute flows make sure you include an “Inital Only” that sets the DN.

Create the Set

Click on All Sets -> New.

I created a set called “_All Users” with the following dynamic rule. Note the cheat on the employee ID – at the moment there is no “Is Present” test, again an inexplicable oversight. As I’m in a test environment at the moment I’m just ensuring all my employeeID values have a “1″ in them. (Note that “employeeID is *” does not work.)

Create the Workflow

Click on Workflows -> New.

The following pictures show how I created the Workflow “_AD Create Users”.

Later note: I think maybe “Add” was not the right choice here because I had some trouble with not being able to remove ERLs later on. Perhaps I should have chosen “Based on Attribute Value” - more testing obviously needed.

Create the Management Policy

Click on Management Policies -> New.

The following pictures show how I created the Management Policy “_AD Create Users”. As I said above, I’m still learning about these objects, so I do not claim this is the right way to configure it – this just shows what I did to get provisioning working, after a fashion.

Configure the ILM MA

You now need to create Import flow rules on the ILM MA to flow all the attributes required by your Synchronization Rule into the metaverse.

Also you must add a flow rule for expected rules list. I never would have figured this out without help from people on the Connect news group.

Testing

Start by creating a user directly in the Portal. Make sure you populate whatever you need to so they are eligible for the Set you created above. You also need to populate the Start Date, so that it is either today, or a day in the past.

After creating the user, check their Provisioning tab – and if you’re really luck you should see that they have an expected rules list with a status of “Pending”.

You can also check the Search Requests page for information about what has (or has not) been going on in the background.

Once you’ve got that pending ERL in place, you should no be ready to run a Full Import and Full Sync of you ILM MA.

Was a new object created in your target MA?

The groups at my work are currently all populated manually in AD. We did discuss the steps needed to move some of the groups into a SQL table where they could be populated using query statements, but we never did get around to it. So I know that the group management capabilities of the ILM 2 Portal are going to be very well received.

ILM MA Export flow rules

I posted last week about doing an intial import of AD groups into ILM, and I’m going to continue on from that point now.

The following table shows the flow rules I set up in my ILM MA that allowed me to import all the information I needed about my groups (both Security and Distribution) into the ILM database. Note that they are all EXPORT flow rules because I’m exporting out of the metaverse.

I had to fabricate values for some of the attributes. While you can actually do the import without such attributes as Owner and MembershipAddWorkflow, you find that you are expected to set values for them when you first edit the group in the Portal. It seemed simpler to flow some sort of intial value into these fields.

Changing a group to Calculated Membership

What I am most interested in at this point is reconfiguring a number of our Distribution Lists that should have a calculated, rather than a manually assigned, membership. As an example I’ll use the group that represents all engineers in the Geneva office.

I should add that I have already imported all the information about my users into Person objects in the ILM db.

The first thing I do is to locate the group under Distribution Lists in the Portal, and change the member selection from “Named” to “Calculated”. This is going to delete the existing members – but only from the ILM db so far.

Next I set the membership select rule. This is nicely intuitive and I think a picture will suffice as explanation.

I can click on the View Members button to see a list of the members inserted by this rule. If it all looks good then I save and submit my changes.

Note that if you set the MembershipAddWorkflow attribute to “Owner Approval” you will need to go through an extra step here to approve the change. See the “Approve Requests” page in the Portal.

Making ILM Authoritative

When I get round to implementing this in production, I will do a one-time import of group data from AD and then switch the master data source to being the ILM Portal. To achieve this I will reverse the direction of the flow rules I created in the ILM MA above, and I will also set the attribute flow precendence in the Metaverse Designer to ensure that changes made in the ILM Portal will make their way through to AD.

What if a group needs to be calculated and manually updated?

This is an old question – what do you do if you want to put all the engineers in a group, but you also want to manually add a couple of other people who wish to see the same emails? And actually ILM2 doesn’t change what the answer to this has been all along: Use nested groups.

So I make my DL Engineer GE group contain two groups: DL Engineer GE Calculated and DL Engineer GE Manual. I can then managed the memberships of these two subgroups through the portal, with the first being “Calculated” and the second being “Named”.

Getting information about my AD users into the ILM Portal went well. I just added a bunch of export flow rules to my ILM MA, ran an Export, and voila! all my users were visible in the Portal.

Unfortunately the groups did not go so well. I kept running into the export error failed-creation-via-web-services, with no idea as to why. Eventually I found a post on the MS Connect newgroup for ILM2 which pointed me in the right direction (I can’t link to the post, but if you search for “failed-via-web-services tips” you’ll find it) – it was to do with the group object schema in the ILM Portal.

Checking the schema requirements

So what you want to do is find out which attributes are essential for the object type you’re trying to export, and what restrictions there are on the possible values.

1. In the ILM Portal, open the Schema Management page (found under Administration).
   
2. Click the All Bindings icon.
   
3. Click on Advanced Search.
   
4. Enter the search criteria:
   • The Binding’s ObjectTypeDescription is Group
   • Attribute IsRequired is True

    
   

5. You should now see a list of the required attributes. You can click on each one to find out more about them. In particular you should check for a regular expression on the Validation tab. Your data must pass the regex (note you can change the regex here if you need to add more possible values).
   
   

 
Populating the values

Some of the required values, like the display name, you can just flow straight from AD. There are a couple of others you can just flow a constant value to – though as you don’t appear to be able to do Advanced rules from the ILM MA you will have to flow the values into the metaverse first from the AD MA.

The Type and Scope will have to be calculated from the groupType attribute in AD, and you will have to set them using the exact terms from the Portal Schema attributes. The following code can be used with advanced import flow rules on the AD MA (the classic type, which I’ve gone back to for the time being).
 

 Case "import_type"
     If csentry("groupType").IntegerValue < 0 Then
         mventry("type").Value = "Security"
     Else
         mventry("type").Value = "Distribution"
     End If

 Case "import_scope"
     Dim groupScope As Long
     If csentry("groupType").IntegerValue < 0 Then
         groupScope = csentry("groupType").IntegerValue + 2147483648
     Else
         groupScope = csentry("groupType").IntegerValue
     End If
     Select Case groupScope
         Case 2
            mventry("scope").Value = "Global"
         Case 4
            mventry("scope").Value = "DomainLocal"
         Case 8
            mventry("scope").Value = "Universal"
     End Select

Once the values are all attached to the group objects in the metaverse it is a simple matter to create the export flow rules on the ILM MA.

I knew that there was going to be a web portal way of doing flow rules with ILM2 – what I didn’t expect was that this would actually be a completely new type of flow rule. Meanwhile the old way (“classic” flow rules) still exists – so we’re going to have ourselves a situation where flow rules can be defined in two different ways through two different interfaces, and there’s no way to view them all together! I can’t say I think this is a very good thing right now.

These new fangled Synchronization Rules

I must say, despite an ever-increasing list of reservations, that the Sync Rules concept in the Portal looks like it will be a lot more intuitive that the old way. The filter, join, projection and attribute flow aspects have all been bundled into the one rule – though of course they’ve had to mess with all that terminology so we now have Connected Object Scope (filter), Relationship Criteria (join), Object Creation in ILM (projection) and just the Attribute Flows have retained the old nomenclature.

Two types of attribute flow rule

During my first attempt at installing this I imported the database from an ILM 2007 server along with all the existing MAs and their flow rules. When I went into the Portal I fully expected to find those rules magically displayed for me…  but it wasn’t the case. It turns out that our old “classic” flow rules can only be accessed through Identity Manager.

But I still assumed that a flow rule created in the Portal would somehow make it’s way into the MA configuration – but again this is not the case – at least not in a visible way. What it does is to create a Synchronization Rule object in your metaverse, which gets sync’d through like any other object, but which somehow, magically, causes invisible join, project and flow rules to run. If you’re used to ILM 2007 and MIIS this is quite disconcerting!

Creating flow rules in the Portal

Still, in an attempt to embrace the new I tried to recreate all our import flow rules from our HR source data as Portal rules.

Immediate plus points:

• It’s very easy to do,
• You can access multiple source attributes (for example, when concatenating FirstName and LastName),
• There are a number of built-in functions available, and
• If the functions don’t meet the need you can wring a bit more flexibility out of the Custom Expression option.

Negatives:

• There were a couple I just couldn’t do, even using a Custom Expression, for example the Advanced Flow Rule we have that replaces all the characters like è,é,ä and ç with more ascii-friendly alternatives, and
• It turns out you can’t write your own functions!

Hybrid Installations

It is possible to run some flow rules via these Synchronization Rule objects and some via the old classic flow rules, and this is what I did to add the couple of flow rules that I couldn’t do the new way. As you can see it appears that I only have two rules – even though I actually have another 17 configured through the Portal.

This is bothering me

I understand that we’re in a transistion period, and it’s good that we still can create true Advanced attribute flows… but I am worried about the troubleshooting and supportability of an installation that has used both types of rule.

The advantage of having the rules in the Portal is clear – MIIS/ILM has long suffered from being murky and backroom, not visible enough to those who need to see what it is up to … and yet, should people be able to create these rules and then not have access to the results of their actions? You can create a rule in the Portal, but you can’t preview it like you can in Identity Manager.

The type of people who I would want to use the Portal – Account Operators, Helpdesk – won’t even think to look for rules in Identity Manager and why should they? They’ve been given this nice web interface – why go anywhere else?

Perhaps all of this will become clearer to me when I start to understand the Workflow and Management Policy aspects of the Portal. I certainly hope so…

Copying the database

One of the great things about ILM is that all configuration is contained in the MicrosoftIdentityIntegrationServer database. So I need only backup the database and then restore it to the new server. Once the Sync Service has been configured to use the new database I should find all my MAs, data and Extension dlls exactly where they should be.

I also needed a copy of the keyset file from the old server. (If you can’t remember where you put it then just export a new one using miiskmu.exe.)

Restoring the database

I found that I had to remove the existing database before I could restore the copied one. I also stopped the Microsoft Identity Integration Server service before beginning.

Reinstalling the Sync Service

I may have been able to attach the new database by using miisactivate.exe, but actually I just went the approach of uninstalling and then reinstalling the Sync Service.

I got a couple of error messages about missing reg keys during the uninstall, but it completed nonetheless. The reinstall went fine and was quite happy to accept the restored database.

It all looked ok…

Everything appeared to be there – until I tried to Sync an MA and got a stopped-extension-dll-invalid-assembly. In the event log is Event 6157 with “The management agent ”AD” failed on run profile “Full Sync”. The run step stopped because the extension dll “MVExtension.dll” is not a valid assembly and could not be loaded.”

Recompiling the code

I initially tried just recompiling an extension in VS2008, but that wasn’t enough.

I then created a new extension project and noticed that MicrosoftIdentityIntegrationServer.dll has been replaced by MicrosoftIdentityIntegrationServerEx.dll. I tried updating my references and recompiling, but the dlls would still not load.

In the end I created new extension projects for the Metaverse and all my MAs and then copied the code across from the old files. After compiling these new dlls, and updating the Extension settings in the MAs, the sync jobs ran!

Logging

While fiddling with the extensions I noticed that MicrosoftIdentityIntegrationServer.Logging has gone missing. This is certainly no great loss for me, I much prefer writing to the Event Log, but some of the code I was porting did make use of it. It’s all commented out now and I will have to put something else in place when I eventually do this migration for real.

Service stopping

The other odd thing was that the MIIS service stopped every time I updated the Extensions folder, and I had to manually restart it. I sincerely hope this is not a new “feature”!

Postscript

I may have managed to get this ILM2 installation looking pretty much like the old ILM 2007 one, but when I tried to add an ILM type MA (this is the one that connects it to the ILM Portal database) I’m getting an error: “Unable to create the management agent. The XML format of the join rules is invalid.”

I guess I’m not there yet…

First I had to decide where to install it

The office ESX farm is awaiting a capacity upgrade so I figured I’d use my demo laptop which is, for the spec nuts, a Lenovo T61 Thinkpad with 4GB of RAM, a dual-core 2.20GHz proc, and 150GB of disk.

I wasted a whole day installing Windows Server 2008 into a VM, using VMWare Workstation running on Vista, but the performance was appalling. I then decided to jump in, boots and all, and rebuild the laptop with Windows 2008 Server. And I must say, I was pleasantly surprised by how effortless this was – the performance bears no comparison as well!

One thought was to skip all the hard stuff and just download the ready-made VM, which should run using Hyper-V on my newly built server/laptop. I may still try this, but the resource requirements are pretty steep – 4GB recommended for the VM, and I only have 4GB available to the whole machine!

So I went ahead with the manual installation, starting by installing SQL 2008, Sharepoint Services 3.0 and all the IIS components, as per this ILM “2″ installation doc, directly onto the laptop’s core OS.

Creating the Service Account

The document stresses the need for a mail-enabled domain account to run the ILM service. This must be a dedicated account – which I think just means the mailbox shouldn’t be used by anything else. Presumably this mailbox will become important in the Workflows.

I created a regular Domain Users account, then added it to local Administrators. In SQL 2008, I created it as a Login and gave it the sysadmin right.

Installing the Sychronization Service

The “MIIS bit” is now called the Synchronization Service. I installed it and, guess what? It looks exactly the same as it always has.

Along the way I encountered this error: “Identity Lifecycle Manager Evaluation Release Candidate requires a running instance of Microsoft SQL Server…”   I was running the installation as an account which belonged to the local Admins, but which I had not yet added as a login in SQL Server – and in fact the installation doc convered this. The installing account must be a SQL Login and it must have the sysadmin right.

Whenever asked for a service account I gave it the domain account I created above. I was unsure whether this was the right thing to do, but so far so good.

Installing the ILM Server

Supposedly this bit will do all the Sharepoint Portal stuff, and the seperate “Object Store” database (are they still calling it that?)

I was again confused by the different accounts requested – you are asked for two during the installation, though it doesn’t ask for a password for the second account (so why ask for the account?).

I attempted to create and use different accounts – during which I got this delightful error from the installation program: “Error -2147217900: failed to execute SQL string, error detail: Specified collection: ‘ReferenceSchemaCollection’ cannot be dropped because it is in use by object ‘dbo.GetMembersNotInSet’.”

In the end I used the same domain account as I had in the Sync Service installation above, and this time it completed.

Post-Install Steps

When I say “completed” I don’t mean “working”. The ILM Portal attempts to open at the end of the installation, and the message was “Error: Access denied”. Nice. I hoped that the post-installation steps from the doc would sort this out.

Firstly, the doc says you may have to manually start the “Microsoft ILM Common Services” – I don’t have this service. Instead I have “Microsoft Identity Manager Lifecycle Services ” (in addition to the familar “Microsoft Identity Integration Server”) so I’m guessing they mean that? It was already started.

The doc also said you might have to manually add the ILM service account into the MIISAdmins group if installing on a different server to the Sync Engine. I installed it all on the same server – but I still had to make the manual group addition.

Next I followed the instructions in the doc to run the stsadm command and give access to the Sharepoint page – however the stsadm command itself refused to run with ”Access denied”. In troubleshooting stsadm:

• I disabled UAC, which didn’t help.
• I then ran the command from the local Administrator account, which did work. Note that I was fully logged in as Administrator – just using “Run As administrator” did not work.

I also spent some fruitless time chasing DCOM errors in the System Event Log.

Reinstall

But I was still seeing that old “Access denied” error. In the end what sorted things out was doing a reinstall of both Sharepoint Services and ILM Server (not the Sync Service – that seemed to be working so I left it alone) and doing it all as local Administrator.  The first time round I had used a domain account that was a member of the local Administrators group. I don’t really see why it should be different, but there you go. Also, when using local Administrator, you’ll have to make up a plausible sounding email address when prompted – I don’t yet know whether this will be a problem later.

We have Portal

So I can see the Portal now, but only when logged in as local Administrator. It’s a start at least!

First a big thank you to the team at Microsoft for releasing a ready-made VM! After completely failing to get the beta 2 version working, with all its complicated software requirements, it was a joy to be able to get the beta 3 up and running so quickly.

The big change with “2″ is the Sharepoint Portal. It has its own database (not sure if they’re still calling this the “Object Store”) which syncs to the familiar MIIS component using it’s own “ILM” MA. You do all your user/group creation and modification in this database, via the Sharepoint Portal. Because it’s built on Sharepoint you can add custom workflows – such as an approval process for group membership requests.

The VM also includes the promised end-user add ons – self-service Password Reset (from the logon splash screen) and self-service Distribution Lists (from an Outlook plugin). I can’t say what the impact will be of adding these in organisations with a lot of desktops, and different versions of Outlook, but they certainly would be useful to have.

The big change is definitely the Sharepoint Portal – it makes ILM look like a whole new product. It certainly makes my job easier when presenting ILM to potential customers – you can really do some nice demonstations: create a user in the portal, sync it through to AD, get the new user to request some mail lists, show the approval cycle… It sure makes a nicer looking demo than showing connector space objects in Identity Manager!

I still have more playing to do – I’m interested in how extensible the Object Store is, and whether I can modify the Sharepoint components. I also want to have a look at the codeless provisioning … but just on immediate impressions - I’m feeling very positive about the new developments.