Our last chapter will focus on helping you keep your MIM system operationally healthy. We will attempt to consolidate known best practices that carry over from previous versions and add some new items that have come from support cases along with the common issues we've seen out in the field.
In this chapter, we will cover the following topics:
Expectations versus reality
Automating run profiles
Backup and restore
SQL health
Sync engine
Rules extensions
The MIM portal
Consider the following real-world scenario: HR IT does not want to provide read-only production access to their system. Instead, they will provide access to their development environment that has production data without private details such as salary and home address. A Management Agent is configured to connect to the development system, and all is working well until it is discovered that a high-ranking executive had access to the business' confidential files for a week. HR confirm that the employee was properly terminated, so the identity management system is blamed for the security breakdown. Analysis discovers that the HR development system is only updated once a week. Different departments voice how they thought the system worked. The building facilities and IT security thought that termination updates disabled accounts immediately even though HR performs terminations at the end of the day. Organizational expectations need to be addressed, which will impact...
Let's first talk about automating your run profiles. Organizations typically run their Management Agents using Task Scheduler or some other task scheduler. To set this up, click on a Management Agent and then click on Configure Run Profiles. Click on the Script button and save the file:
If you save it as a VB Script file, you can run the particular run profile by running cscript filename.vbs. As VB Script is making a simple call to WMI, you could use PowerShell too. Whether you want to run your imports, synchronizations, and exports using Task Scheduler or some other product is up to you; just know that you will need to start the run profiles with a WMI call.
If you save the run profile as a C# file, you can compile the file into an executable (.exe) with csc.exe from a Visual Studio command prompt. Here is an example of compiling C:\SourceCode\HRFullImport.cs into C:\Scripts\HR-FI.exe:
csc C:\SourceCode\HRFullImport.cs /out:C:\Scripts\HR-FI.exe
As we have mentioned...
Any best practice worth repeating should apply to any MIM solution no matter how complex. Some MIM best practices are industry-standard concepts, such as performing a backup and verifying system backups, while others refer to specific technology, such as the operating system or SQL. We will now point you to the resources for the backup and restoring of the main components and discuss specific SQL and MIM best practices.
Rather than rewriting Microsoft's backup and restore guidelines, we have chosen to direct you to the official documents and then to summarize some key points. Note that some of the documents were written for MIM's predecessor, FIM, but still hold true:
Backup and Restore Guide for FIM 2010 (http://bit.ly/MIMBackupRestoreGuide)
FIM CM Backup and Restore (http://bit.ly/MIMCMBackupAndRestore)
FIM Reporting Disaster Recovery (http://bit.ly/MIMReportingRecovery)
SCSM Disaster Recovery Guide (http://bit.ly/SCSMDisasterRecoveryGuide)
High availability and PAM disaster recovery (http://bit.ly/MIMPAMDisasterRecovery)
Back up the synchronization encryption key by running the Synchronization Service Key Management tool, select Export key set, and enter the Synchronization Service account credentials. Keep this file in a secured location as the key is used to securely store the password for accounts not yet provisioned.
A backup of the SQL database will include the schema, Management Agents, and even the rules extensions (they are stored as binary blobs in the database), but it can be handy to have just the Management Agents and Metaverse configuration saved and backed up separately. You do not need to stop the MIM Synchronization service before performing the backup, but you should verify no Management Agents are running because a running Management Agent means data is being processed.
The most common restore problem with the MIM Synchronization service database is a lost encryption key. If you need to restore the database without providing the encryption key, you will lose all MA connection settings and will have to reconfigure them. Re-entering service account passwords and clicking on Next a few times may seem a minor thing, but keep in mind that you will lose any initial passwords of users that are in the process of being provisioned. If you look at the pending exports...
The MIM service database is probably the most important database for you to back up because you probably have authoritative data in it. The MIM portal database will hold resources, attributes, workflows, MPR objects, and resource relations, among others. If you are using the MIM portal to create or update resources or you've deployed self-service password reset, backup is critical.
According to the Backup and Restore guide for FIM 2010, the recommendation is to perform at least a full daily backup of the FIM service database. If you are not performing incremental backups, then set the database in simple recovery mode. You do not have to stop the FIM service when you create the backup.
Other files that should be backed up when modified are as follows:
The .NET application configuration file in %programfiles%\Forefront Identity Manager\2010\Service\Microsoft.ResourceManagement.Service.exe.config
The registry keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet...
There are a lot of moving parts to the system depending on the components you have installed. How do you know if your system is healthy? Here are a few items to watch:
The Synchronization Service Operation tool should have no errors
MIM portal requests should show successful completion (Completed)
MIM SQL jobs should be successful
The Windows Application and Forefront Identity Manager event logs should be shown
SQL and/or clustering logs should be shown
The duration of synchronizations and imports and exports over time for each Management Agent should be monitored
If a Management Agent is taking longer to complete its run operation, there are few things to consider. If you have a delay in an export or import operation, there could be a problem with the source system or network. Initial investigations for longer-than-expected synchronizations should determine whether a large number of groups is being synchronized, whether non-indexed attributes are being used as joins, or whether there are SQL Server performance problems.
If the MIM portal takes a long time to respond or times out while performing a "contains" search, it could be because the full-text search catalog needs to be rebuilt. Start SQL Management Studio and click on Databases | FIMService | Storage | Full Text Catalogs. Right-click on ftCatalog and select Rebuild:
If your portal's search performance is slow for "non-contain" searches, then you may need to rebuild the indexes and update the statistics of the service database. The following query can be used to determine...
Microsoft's official best practices for FIM holds true for MIM too. These items should be implemented before releasing the system to a production environment. We have highlighted several SQL practices that we've found to solve customer problems:
Never modify any of the MIM database tables directly in SQL because you can corrupt the database.
Do not query the Metaverse table within a rules extension, workflow, or external process. Doing so creates SQL deadlock conditions that MIM would not expect.
Do not change SQL permissions set by the MIM installer.
The Synchronization service database and MIM Service database should be in their own SQL instances and on different disks, if possible.
Isolate the SQL data and log files on different disks.
Presize the SQL databases and avoid relying on SQL autogrow to improve performance.
Monitor SQL databases to ensure that there is enough disk space.
Limit the amount of memory that SQL will use if SQL is running on the same server as the sync...
Here are some of MIM synchronization's best practices to follow:
The account used for the MIM Synchronization service should be different from the account used for the MIM Service MA.
The source code for all rules extensions should be backed up and maintained in a source control program. You will need the source code if you ever need to debug a rules extension.
When writing a rule extension, check whether the attribute is present before looking for a value. An example is as follows:
if (csentry["department"].IsPresent) {...}We suggest performing a full import run profile and a full synchronization on each MA at least every 30 days.
Clear the synchronization operational run history regularly as the data will make the database grow over time and have an impact on its performance.
Avoid using the Joiner tool as much as possible because any explicitly joined or projected object will not honor existing or future...
The following are some best practices of the MIM portal:
Minimize the use of dynamic nesting and the use of negative (NOT) conditions in sets and groups. A good rule of thumb is to stay under five NOTs.
Disable the verbose tracing of MIM Service when not needed.
Be aware that exposing self-service reset internal and external could be a Denial of Service endpoint if you have Active Directory configured to lock out.
Back up custom workflow code and pages and manage them as you would any production source code.
Do not delete the default workflows that come with the product.
Keep an eye on expired portal requests. If you see requests building up beyond the retention time (default 30 days), then you may need to run the SQL job FIM_DeleteExpiredSystemObjectsJob.
Hear us now and thank us later; back up the databases and configurations prior to making a configuration change or applying an update.
Do not run your MIM service accounts in the enterprise admin, domain admin, schema admin, or account operator Active Directory groups.
Disable SharePoint indexing if you have deployed the MIM portal.
Try to keep the product up to date with the latest update as much as possible as the latest update fixes bugs and sometimes add new features and performance enhancements. Updates are found at http://bit.ly/MSFTIDMUpdates.
Also refer to the MIM 2016 Help file for Best Practices and Microsoft's own best practices page at http://bit.ly/MIMMSFTBestPractices.
We discussed some best practices, informed you how to perform maintenance on your MIM databases, referenced backup and restore procedures, showed how to automate run profiles, and discussed how business assumptions can turn into operational issues. Did we cover everything about MIM? Absolutely not. We did cover the core functionality of the product from installation to troubleshooting, the primary concepts and terminology, and potential pitfalls and best practices. We hope you find the book informative and helpful in your identity management adventures.
© 2016 Packt Publishing Limited All Rights Reserved
