The most time critical aspect of an MIIS installation is likely to be the Password Sync. There are always going to be delays in syncs through the MAs, and people should be used to that – but when a user changes their password they are going to expect it to go straight through.
If you are regularly replicating MIIS to a failover server then you can have password sync up and running within a matter of minutes after a failure of your primary server.
I take the precaution of pre-registering my failover server with PCNS. When you installed Password Sync you would have run the SETSPN and PCNSCFG ADDTARGET commands to enable your MIIS server as a password sync target for PCNS. You should now also execute these commands for your failover server, adding an extra one to disable it until needed.
This post is not intended to be an instruction on installing PCNS – for that you should refer to this Technet document. So, on the assumption that you’ve already got PCNS working for you primary MIIS server, you just need to run these extra commands to register your failover server.
setspn.exe -A PCNSCLNT/failoverserverDN domainsvcaccount
pcnscfg.exe addtarget /n:miispw_failoverserver /a:failoverserverDN
/s:PCNSCLNT/failoverserverDN /fi:”Domain Users” /f:3pcnscfg disabletarget failoverserverDN
You now have the failover server registered, but disabled. To confirm this use the command
pcnscfg list
When you’re ready to switch from your primary to failover server all you need to do is execute these commands:
pcnscfg disabletarget primaryserverDN
pcnscfg enabletarget failoverserverDN
The failover MIIS server should now be able to sync the passwords of all the users it knows about.
Of course, if new users have been created since the last time you replicated the MicrosoftIdentityIntegrationServer database then the failover server can’t be expected to know about them until you’ve done your re-sync’ing work. But at least, in the meantime, Password Sync will be working for the majority of your users. And that’s what I’d call a very successful DR plan!
One thing that needs to be mentions here is that when you disable a target, you lose all of the pending password changes.
Which is not a very good thing. If there are no jobs pending, then I would agree with the above statement.
A better method would to alter the existing target this way you can still receive those pending password changes that are in the queue.
Joe Stepongzi
http://www.microsoftidm.com
I like this method, though I am considering taking a slightly different approach. Because I’m the ILM guy but not a Domain Admin, I’m thinking of requesting the separate PCNS target be configured for the DR server and have a different group specified for inclusion. I’d leave the secondary target enabled. I can get the group management permissions delegated to me, and then if I need to test the DR server I can just drop my account or a test account into that group. In the case of a real disaster, I can remove Domain Users from the group that is included on the production target and add it to the DR include group. That way I don’t need direct access to a DC and the pcnscfg utility. Domain Users wasn’t directly included in the production target because we had a pilot deployment with a limited number of users first, so we first nested the pilot group in the include group, later adding Domain Users.
Of course, this method has the same limitation that steponz points out. My thought is that if the ILM server does go down and passwords stop syncing, the users aren’t going to know and they’re going to keep trying to reset their password and if I managed to keep all those password notifications the end result might not be what the user expected anyway as I believe each DC keeps trying to send its own notification every minute or however it is configured.
Hiya Chris,
There’s one flaw in your plan: group changes are not effective until the user logs out and logs back in again. But yes I agree, PCNS changes are a pain when you don’t have the permissions, as I’ve recently been finding out at a client site.