So,Â I have a bit of time this week while the year gets started, and thought I would spend it playing with theÂ latest evaluationÂ version of ILM “2”. I hope to upgrade my company’s system at some point, so my first plan is to see if I can import the existing ILM 2007Â database into it – but before I can get there, I obviously need to install the thing.
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.
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.
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!