Okay, there is enough information there on how to upgrade. I am going to focus on things to watch for before and after the upgrade.
Before the upgrade
Know your system and how it is used
In my experience with FIM/MIM deployments the biggest gap has been how well the current Admin/Architect knows their system. Some discovery questions I would recommend are
- Is the system well documented? And I don’t mean the documentation that was done by the consultants who built the system years ago. Hopefully if you are in an environment with a solid change control process, there would be system documentation update for changes.
- Is there a catalog of services that FIM provides? Almost everywhere I have asked this question has returned a blank face. If your approach to IT products is that of service provided to the customer (the user) then you should have a catalog of services that the product provides. I know if you are an IT provider or in a corporate environment where there is IT service charge back you would have this information. This information is one that I advise all FIM admins should have and update it regularly. For an upgrade, you want to be able to answer what service should still be provided to my customers after the upgrade?
- Are there any current or pending issues?
- What are the current pain points?
- What is the reason for the upgrade? These 3 questions are kind of rolled up. The FIM Admin should tell you about any reported system issues and what improvements they expect from the MIM upgrade.
Do your own discovery
- What is the FIM build number? What is the upgrade path for the build?
- Existing documentation: Read existing documentation, very likely they will be pre-historic information but it’s at least a start.
- Export the FIM Server config and Portal config and use the FIM documenter to create documents from the config. Review the document and highlight any potential red flags.
- Look at the FIM Sync Operations logs. Are there any red flags? Custom ECMA errors? Are Syncs not completing? Is there any MA that is giving problems? Are there sync errors that are being ignored?
- How are the sync jobs running? Are they following best practice and running single not combined job profiles? Example running Delta Sync then Delta Import, not Delta Sync and Delta Import. Is there a pause between MA run jobs?
- Look at the FIM Sync Event logs. Are there errors related to the sync?
- Are there any extensions code? Is the original source code available?
- Look at the FIM Portal request logs. Are there workflow errors? Are there SSPR errors? Watch that carefully, because users do not always report SSPR errors when they can just call the Helpdesk to reset the password. Are there a number of SSPR denies? Are there SSPR authentication timeouts? Are the same users repeatedly trying to change their passwords or register? Are SSPR add-ins in use? Do users have issues with it?
- In FIM Portal, are you using any third party workflow? Or even MIM WAL. Does it work with MIM? Are there any current issues with the workflows? If an upgrade is needed to work with MIM, I would say to do that upgrade first before the upgrade.
- How are the workflows configured? Are there a lot of PowerShell workflows making changes to external directories?
- Have there been SQL issues in the past? Have there been issues with Temporal jobs? Are there any other custom SP jobs, could be a Store procedure being used for sync or it could be SQL email alert setup for FIM jobs.
- Are there any SQL DBs that are part of the FIM synchronization process? Or perhaps DBs that are used for FIM related scripting?
- Are there scheduled scripts that access the FIM Webservice? If there are local scripts there should be no problem but if there are remote scripts that admins run and you
- Are they using NLB? How do they use it for FIM?
- Are you using PCNS? Do you want to upgrade the PCNS to the latest? Plan to do that before the upgrade
Is FIM Sync/Portal/SSPR different?
You know, I thought MIM and FIM were identical twin brothers, just like we make mistakes about identical twins and treat both as one and not recognizing that they have their own unique innuendos, we can also make the same mistake with FIM and MIM. There are subtle difference between the two that I have noticed and that is why your discovery is very important.
- MIM Sync I think is more sensitive to MA job errors or failures than FIM. Follow best practice for job runs is my recommendation.
- MIM SSPR is more sensitive to SSPR errors. The code design is slightly different. I would advise to use resolve SSPR issues before upgrade especially with the add-ins. It is difficult to find this because users don’t report it, but check for SSPR anomalies in the FIM service event and request logs.
Items to get ready before the upgrade
- Any firewall settings: For SSPR, for FIM Portal, Sync. There may be
- Network firewall setting: Internal or external firewall
- Windows firewall settings
- Application firewall settings: For instance some HR environments use the Oracle Firewall to shield their HR DB so if you are doing an upgrade to a new server, you would need to permission this new server.
- SMTP gateway filters: If you are using new servers, give the servers permission.
- Get physical servers ready: Seeing sizing blog post for details. Do you go with more memory, more drives? Do you partition? Analysis of your request logs will answer these questions.
- New OS: Do you go to W2k12 from W2k8 or to W2k16? Decision is up to you. But I must point out that there is considerable difference between W2k12 and W2k8 especially wrt to PowerShell libraries. In W2k8 you call “Import AD Module” in your workflows because the default PowerShell version is ver2 (DNet 3.51 compiled) and the FIM/MIM is DNet 3.51 compiled, but in W2k12, the default PS is ver3 which is DNet 4.0 compiled so “Import AD Module” will no longer work. You may have to also re-write some of your PowerShell scripts. See my blogpost on this. See blogpost on alternative to import AD module.
- Lync/O365 modules: Some of the earlier O365 PowerShell modules were compiled in DNet 3.51, so they can be loaded in the FIM/MIM workflows. If you download the latest, they are compiled in DotNet 4 and so cannot be loaded. Stay with the modules that you are currently using, if you run your PowerShell scripts in the workflow engine not outside.
- SQL upgrade: Do you go to SQL 2014 or 2016? Decision is up to you. I wouldn’t say one is better than the other wrt MIM.
- What SharePoint to use: The options are
- SPF2013 is the last free version of SharePoint
- SPF2013 won’t install on Windows Server 2016 without a bunch of fiddling around
- SPF2013 is not compatible with SQL Server 2016
- There is extra licensing cost with SharePoint 2016
My recommendation is stay with SPF2013 unless you are going with SQL 2016. Also if you install SharePoint new, turn off all SP services not needed.
- Network Load Balance: The configuration will have to be updated for new MIM servers
- DNS (Internal and External), SPNs: The configuration will have to be updated for new MIM servers
- Certificates: For new MIM servers get certificates (local and public) ready and installed.
- Passwords: Get passwords to all the management agents and the service accounts.
- Accounts: Create new MIM accounts or reuse FIM accounts? I would say re-use the FIM accounts but if you decide to use new accounts, you should make the change before the upgrade. See my blog post on changing FIM accounts.
- Upgrade any custom workflows: This could be MIM WAL or any other libraries. The upgrade is not required but you may decide you want to or the vendor may advice that you should. When you upgrade custom workflow library and you GAC in an updated dll file to replace the previous dll, go to each workflow that contains an activity from your custom library, make a change from the GUI some something trivial, I add a space to the activity display name and then save it. That recompiles the activity and links up the new dll in the xoml. I tried to do this via PS but it just wouldn’t work. Thinking back if you do it for one, look a the before and after of the xoml, see what is the new dll reference placed in the xoml and the use PS to make changes to others. If you have 100+ workflows to amend, doing it via the GUI can be a long task. Caution also about doing it via GUI, for workflows that have activity, set the Dotnet back to 3.5 after saving.
The day of the Upgrade
- Get the MIM software ready. Remember the upgrade path recommended is
A/ FIM 2010 R2 SP1 => MIM RTM => MIM SP1 => Post MIM SP1 patch. So have MIM RTM, MIM SP1, Post MIM SP1 patch.
B/ FIM 2010 R2 SP1 => MIM SP1 => Post MIM SP1 patch. See instructions here. So have MIM SP1, Post MIM SP1 patch ready.
For both Post MIM SP1 patch install this one. It has fixes to some issues I have seen post upgrade
- Backup your FIM Sync keys, DBs and VMs.
- Backup key files such as
- The FIM service Resourcemanagement.config file and the web.config file for the Portal.
- The SSPR customizations folder and webconfig file.
- The FIM sync extension folder
- If you customized your FIM then back up the aspx folders
- Have your checkout plan ready.
- Are there multiple FIM Portal servers? I would say that when upgrading one turn off the FIM service on the other one, so there is no connections to the FIM service DB. Generally, the upgrade software should detect if the DB has been upgraded or not.
After the upgrade
Here are some key items to check
- PCNS: If you use PCNS, go to the Sync Engine, Options and enable Password synchronization button, the upgrade process can uncheck that box.
- If you have a PowerShell MA which is a separate install file, then run the install and install the connector software.
- Run the sync jobs: My experience on new MIM servers? Had to enter all the MA passwords fresh. So have the passwords ready, with in-place upgrade I did not have to so
- Verify Portal access: Attempt to log into the portal. If this fails disable friendly error message page so you can see the real error and troubleshoot.
- Restore FIM service config files.
- Update the Microsoft.ResourceManagement.Service.exe.config settings. I have seen for inplace upgrade where the MIM dll files were not being referenced in the config file.
- Update the web.config file
- Install the MIM WAL or any Workflow library you have
- Check the MIM SQL agent Temporal jobs
- Go to SQL Studio
- Make sure MIM Agent jobs are present especially the TemporalEvents job
- Go to the properties of the TemporalEvents job, disable and enable the schedule
- Set a custom schedule (like in the next hr)
- Confirm Job is triggered off and completes successfully
- Set the schedule back to the MIM assigned schedule (1am daily)
- Verify Enduser tasks
- Verify IT support tasks
- Verify OOB workflow
- Verify custom workflow
- Verify approval workflow
- Verify email notification workflow
- Verify account provision and deprovision
- Verify that when users get email notifications they can click on the links in the email
- Verify that all catalog of services work.