ILM 2 Beta - Get Your Service Account(s) On

Say goodbye to the simple days of two or three service accounts to run ILM. I'm not talking about the various accounts you might have to run the MA's you have, but the accounts used to run the Services themselves. An existing implementation might have the following basic accounts:

• ILM Service Account - the service, miiserver
• ILM Install Account - used by some instances where a separate account is needed that has sa rights to SQL for app and patch installs
• MA Account(s) - used to access data sources like AD, SQL, etc...

...and don't forget the SQL Service Account. For ILM 2 I've been trying to get my head around all of the new requirements so we can build our internal standards around what each account is named and what it is used for. Here is what I have so far:

• svc.sql - no change here, this is our SQL Server account and there may, in fact, be others for the Agent, SSIS, etc...
• svc.wss - Windows SharePoint Services needs an account to run the AppPool that the default Site Collection runs under
• svc.wssfarm - Windows SharePoint Services need an account to run the AppPool that the Central Administration site runs under as well as the Timer service
• svc.ilmsync - This is the account that runs the sync engine - good old miiserver
• svc.ilmma - This is the special synchronization account used for the ILM MA to communicate with the Web Services
• svc.ilmws - This is the account for the new ILM Web Service (Microsoft ILM Common Services)

Note that I'm not making use of Network Service here - I want Kerberos delegation (once multiple tiers are supported) to be from service account to service account and if you use local security principals like Network Service or Local System you have to delegate from the computer account.

Most of the above accounts make sense, with the exception of the special sync account - svc.ilmma. This account shows up during the ILM Server installation and appears in two places you should be aware of:

• Program Files\Microsoft Identity Management\Common Services\Microsoft.ResourceManagement.Service.exe.config - the appSettings tag references it as the SyncEngineAccount property seen here:

<appSettings>    

<!-- Setup adds entries -->    

  <add key="mailServer" value="mail.ensynch.info"/>

  <add key="isExchange" value="0"/>

  <add key="sendAsAddress" value="svc.ilmws@ensynch.info"/>

  <add key="synchronizationServerName" value="ENS-ILM01"/>

  <add key="SyncEngineAccount" value="info\svc.ilmma"/>

</appSettings>

• ILM MA - in order to read and write to the new MSILM database you have to use the special sync account. Now, if you're tempted to use the same account you used for the webservice, it will read successfully; however you will not be able to write, observe:

If you don't use the account you specified at setup for the Sync Engine Account as the identity powering the ILM MA then you're attempts to Export will be frustrated by cd-errors. They are nasty, vicious, brutal and don't have any error descriptions (at least in beta 3). And, if you're wondering, while this account is not delegated rights to the MSILM database in SQL it does have to be in the MIISAdmins group. It has to be in this group because of the new dependencies for Synchronization Rules. If you think about it, it makes sense - the ILM portal is passing down a configuration set and the engine is processing it...using the credentials specified in the ILM MA...which had better have rights to make configuration changes in ILM.