Karchworld Identity

Automating Rebuilding of FIM Service Database Full-Text Index Catalogs

2013-05-02T13:19:25Z

A recommend practice is the regular rebuilding of the full text catalog for the FIM Service database, since this optimizes performance of FIM queries. Without attention to maintaining this catalog one may experience SQL timeouts occurring leading to failures in FIM requests.

This blog entry contains the instructions on how to set up the automation to rebuild the full-text indexes at 1:00am each night.

Implementation Steps

Login a workstation or server that has Microsoft SQL Server Management Studio installed on it with an account that has administrative rights on the SQL server.
Launch SQL Server Management Studio.
From the SQL Servicer Management Studio’s Object Explorer tree view on the left, navigate Databases --> FIMService --> Storage --> Full Text Catalogs
Right-click on the ftCatalog node under Full Text Catalogs and select Properties. The Full-Text Catalog Properties window will appear.
On the Full-Text Catalog Properties window, select the Populate Schedule item from the menu on the left and then click the New button. The New Full-Text Indexing Catalog Schedule dialog will appear.
On the New Full-Text Indexing Catalog Schedule dialog, enter in the following values:
• Name: Nightly Rebuild of Indexes
• Enabled: checked
• Schedule Type: Reoccuring
• Frequency:
• Occurs: Daily
• Recurs every: 1 day
• Daily frequency:
• Occurs once at: 01:00 AM
• Duration
• Start date: (today’s date)
• No end date: selected
On the New Full-Text Indexing Catalog Schedule dialog, click the OK button. The New Full-Text Indexing Catalog Schedule dialog will close.
On the Full-Text Catalog Properties window, click the OK button. The Full-Text Catalog Properties window will close.

Automating the Clearing of a FIM Synchronization Server's of Run History

2013-05-02T13:09:00Z

As many of you know, periodically clearing of the FIM Synchronization Server's Run History is not only a good idea, it's a recommended practice. Since the run history is stored in the FIMSynchronizationService database, doing so serves to minimize the growth of it, which otherwise can grow to extreme sizes after a period of time if left unchecked. Doing so not only conserves space, but also serves to ensure that there is no degradation of performance in the moving between Management Agents and Operations tabs in the Synchronization Server Console. Anyway, enough with the sermon to the choir.

This blog entry contains three parts:

Part I - Instructions on how to set up the automate the clearing of the run history on the first of each month.
Part II - The scheduled task XML file that you can simply import into yoru scheduled task library and turn on
Part III - The PowerShell script that will the scheduled task will call to clear the logs.

Part I - Instructions:

Save the XML document in Part II to a file called FIM Clear History Runs.xml
Save the PowerShell document in Part III to a file called FIMClearRuns.ps1
Login the FIM Synchronization server with an account that is a member of the Domain Admins security group.
Open Windows Explorer and create a new folder called Scripts under the following path: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service. (Note: Do not change the location of this folder without also updating the XML file in Part II)
Into the previously created folder, copy the following files from the deployment package:
• FIMClearRuns.ps1
• FIM Clear History Runs.xml
Open the Windows Task Scheduler by navigating, Start --> Administrator Tools --> Task Scheduler.
From the tree view on the left of the Task Scheduler, select and then right-click on the Task Scheduler Library entry and select New Folder. In the textbox on the modal dialog that appears, enter in the name FIM Automation and then click the OK button. The dialog will close and the folder will be created.
From the tree view on the left of the Task Scheduler, select and then right-click on the newly created FIM Automation folder and select Import Task. An Open File dialog will appear.
From the Open File dialog, navigate to the FIM Incremental Sync.xml file located in the following folder: C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Scripts. The Create Task dialog will appear.
On the Create Task dialog, click the Change User button and update the service account that should be used to execute the PowerShell file. I recommend the user of the FIM Sync Service account.
On the Create Task dialog, click OK button. A dialog will appear to prompt you for the password for the service account specified to run this task. Enter the password for this account and click the OK button. Both dialogs will then close and the scheduled task ought to appear in the list under this folder.

Part II - FIM Clear History Runs.xml

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.3" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
    <Date>2013-04-12T12:59:00.5037425</Date>
    <Author>NMIS\karcher_adm</Author>
</RegistrationInfo>
<Triggers>
    <CalendarTrigger>
      <StartBoundary>2011-02-28T01:00:00</StartBoundary>
      <Enabled>true</Enabled>
      <ScheduleByMonth>
        <DaysOfMonth>
          <Day>1</Day>
        </DaysOfMonth>
        <Months>
          <January />
          <February />
          <March />
          <April />
          <May />
          <June />
          <July />
          <August />
          <September />
          <October />
          <November />
          <December />
        </Months>
      </ScheduleByMonth>
    </CalendarTrigger>
</Triggers>
<Principals>
    <Principal id="Author">
      <UserId>DOMAIN\FIM-SYNC-ACCOUNT</UserId>
      <LogonType>Password</LogonType>
      <RunLevel>HighestAvailable</RunLevel>
    </Principal>
</Principals>
<Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>true</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <DisallowStartOnRemoteAppSession>false</DisallowStartOnRemoteAppSession>
    <UseUnifiedSchedulingEngine>false</UseUnifiedSchedulingEngine>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>PT4H</ExecutionTimeLimit>
    <Priority>7</Priority>
</Settings>
<Actions Context="Author">
    <Exec>
      <Command>powershell.exe</Command>
      <Arguments>-command "& 'C:\Program Files\Microsoft Forefront Identity Manager\Scripts\FIMClearRuns.ps1'"</Arguments>
    </Exec>
</Actions>
</Task>

Part III - FIMClearRuns.ps1

####################################################################################################
# Script Name: FIMClearRuns.ps1
# Author: Erich Karch
# Company: Microsoft Corporation
# Date: 03/24/2011
# Description: Performs a backup of the FIM run history then clears the runs
####################################################################################################

# Define Variables

$filePath = "C:\Program Files\Microsoft Forefront Identity Manager\Logs\Run History"

# Script Logic

$today = Get-Date
[datetime]$clearRunsEndingBefore = $today.ToString("yyyy-MM-01")
$fileName = "Run History for " + $clearRunsEndingBefore.AddDays(-1).ToString("yyyy-MM") + ".log"

if ((Test-Path $filePath) -eq $false)
{
New-Item $filePath -type Directory
}

New-Item -path $filePath -name $fileName -type File

$runs = Get-WmiObject -Class MIIS_RunHistory -Namespace root/MicrosoftIdentityIntegrationServer

$runs | ForEach-Object {
$run = $_

If ([datetime]$run.RunEndTime -lt $clearRunsEndingBefore)
{
Write-Host ('Exporting ' + $run.RunEndTime)

$run.RunDetails().ReturnValue >> $filePath\$fileName
}
}

$mc = Get-WmiObject MIIS_Server -Namespace 'ROOT\MicrosoftIdentityIntegrationServer'
$inParams = $mc.psbase.GetMethodParameters('ClearRuns')
$inParams.EndingBefore = $clearRunsEndingBefore
$mc.psbase.InvokeMethod('ClearRuns', $inParams, $null)

Powershell: Create 1000 Test User Accounts

2013-04-01T18:59:00Z

For those looking for populate a test domain -- oooh with say a 1000 users with distinct user attribute values -- here is a script that I think will do you just fine:

Import-Module ActiveDirectory

$total = 1000
for ($userIndex=0; $userIndex -lt $total; $userIndex++)
{
$userID = "{0:0000}" -f ($userIndex + 1)
$userName = "test.user$userID"

Write-Host "Creating user" ($userIndex + 1) "of" $total ":" $userName

  New-ADUser `
   -AccountPassword (ConvertTo-SecureString "AAaaAAaa11!!11" -AsPlainText -Force) `
   -City "City" `
   -Company "Company" `
   -Country "US" `
   -Department "Department" `
   -Description ("TEST ACCOUNT " + $userID + ": This user account does not represent a real user and is meant for test purposes only")`
   -DisplayName "Test User ($userID)" `
   -Division "Division" `
   -EmailAddress "$userName@karchworld.local" `
  -EmployeeNumber "$userID" `
   -EmployeeID "ISED$userID" `
   -Enabled $true `
   -Fax "703-555-$userID" `
   -GivenName "Test" `
   -HomePhone "703-556-$userID" `
   -Initials "TU$userID" `
   -MobilePhone "703-557-$userID" `
   -Name "Test User ($userID)" `
   -Office "Office: $userID"`
   -OfficePhone "703-558-$userID" `
   -Organization "Organization" `
   -Path "OU=Users,,DC=KARCHWORLD,DC=LOCAL" `
   -POBox "PO Box $userID"`
   -PostalCode $userID `
   -SamAccountName $userName `
   -State "VA - Virginia" `
   -StreetAddress "$userID Any Street" `
   -Surname "User ($userID)" `
   -Title "Title" `
   -UserPrincipalName "$userName@karchworld.local"
}

FIM 2010 Kerberos Overview & Setup

2013-01-22T18:25:00Z

I don't usually do this, but I came across just a great article on how FIM 2010 utilizes Kerberos for securing communications between its components, that I thought I would share it:

FIM 2010 Kerberos Setup by Thomas Vuylsteke

...What a great piece of IP

Automating FIM Syncs but "A Specified Logon Session Does Not Exist!" WTF does that mean?

2013-01-10T18:42:00Z

Personally, I think it would be really nice -- and perhaps is long overdue -- for the FIM Synchronization engine to provide functionality to allow for the automated execution of run profiles on a schedule, but until that sweet day, we need to use the standard process of exectuing the run profiles via a script, initiated from a scheduled task.

Anyway, I digress...

This morning, while attempting to create a scheduled task to run my automation script (under the security context of a service account WITH a persisted password), this usually routine effort was thwarted with the following error message when I attempted to save it:

An error has occurred for task [NAME OF SCHEDULED TASK]. Error Message: The following error was reported: A specified logon session does not exist. It may already have been terminated.

What this jibber-jabber is saying is that there is a local policy preventing you from persisting (i.e. storing) the specified service account's password.

To verify this:

Open up your Local Security Policies.
Navigate to Security Settings --> Local Policies --> Security Options
Open up the policy, Network access: Do not allow storage of passwords and credentials for network authentication
If that locally is enabled, you will need to disable it in order to persist the password for your service account.

As usual, if your ability to change it is grayed out otherwise unavailable, you either do not have rights to change the policy or the policy is controlled by GPO. Either way, you will need to disable this policy in order to get past this.

Good luck!

FIM 2010 R2 SSPR Portals - 503: Service Unavailable / App Pool Services Stopping

2012-10-09T11:53:03Z

This is a quick one and one I am going to jot down because sometimes the resolution to issues is really quite simple.

Last night, I deployed SSPR onto its own server, and in my validation of the implementation, each time I accessed one of the SSPR portals I would get a 503 error (i.e. service unavailable) with no corresponding event entry getting logged. Stepping through it, I notice that the app pool services were running, but when I would hit either the registration or reset portals, the services would stop. Weird eh?

Weird yes, but simple to fix. Check to make sure that the password for the app pool service account is correct. Reset it in AD and/or reset it in IIS Manager to bring them in-line. $10.00 says that this fixes the issue.

Hope this helps if you have this too

Installing FIM SSPR Portals & Error: "Unable to connect to the Internet Information Server (Error: -2147221164)"

2012-10-03T01:20:27Z

This evening, I was installing the FIM 2010 R2 Self-Server Password Register and Reset portals on a server when I received the following error (sorry I didn't take a screen-shot):

"Unable to connect to the Internet Information Server (Error: -2147221164)"

A quick Bing search of the error code resulted in nothing -- I didn't bother with Google -- and being that the error description is not bad but not too helpful either, I thought I'd whip together a quick blog entry on what the issue was in case I (or whomever reading this) run into it again. Turns out, the guys who built the server deployed the wrong IIS server role services. If you receive this error, enumerate the following IIS 7.5 web server and management tool role services to make sure they are deployed:

Required IIS 7.5 Web Server Role Services

Role service	Required features
Common HTTP Features	Static Content Default Document Directory Browsing HTTP Errors HTTP Redirection
Application Development	ASP .NET .NET Extensibility ISAPI Extensions ISAPI Filters
Health and Diagnostics	HTTP Logging Request Monitor
Security	Basic Authentication Windows Authentication Request Filtering
Performance	Static Content Compression Dynamic Content Compression

Required IIS 7.5 Management Tools Role Services

Role service	Required features
IIS Management Console
IIS 6 Management Compatibility	IIS 6 Metabase Compatibility IIS 6 WMI Compatibility IIS 6 Scripting Tools IIS 6 Management Console

Forefront Identity Manager Synchronization Service is having trouble contacting SQL server -- Bah!

2012-10-01T18:47:15Z

When installing FIM, do you ever get one of these:

"Forefront Identity Manager Synchronization Service is having trouble contacting SQL server using the provided information. Please note that Forefront Identity Manager Synchronization Service requires Microsoft SQL Server 2008 SP1 or better. Verify the version, server and instance names as well as firewall settings and try again."

99 times out of 100, the issue turns outt hat you fat-fingered or simply have the server and instance names wrong. However, for that 1 time out of a 100, it can be frustrating to debug. I ran into the one of these times this morning and thought I'd put together a check list for the next I (or you) need it:

Double check that you indeed did not fat-finger or simpy are using the wrong server and host names.
Verify that you can access the server via an ODBC connection going to: Administrator Tools --> Data Sources --> User DSN tab --> Add --> Fill in the server information --> Click "Test Connection"
Check the firewall rules / See if you can telnet to the server via: telnet XX.XX.XX.XX: 1433
Disable IESC for Administrators if it is on
Verify that Full Text Server is installed on the SQL server.
Verify that SQL Agent and Browser (if you are not using the default instance) are running.
Verify that the SQL Native Client is installed.

Hope this helps!

SQL Server MA Resulting throwing "stopped-server" Exception

2012-09-27T23:13:15Z

Last night, the one of our SQL MAs stopped working correctly with no apparent reason. Whatever happened, the result was that every time we run a full import on one of our SQL MAs, it reports a status of stopped-server. Literally, running a full import was causing the FIM Synchronization service to stop! Bizzare

Looking in the Event Viewer showed:

The Forefront Identity Manager Synchronization Service service terminated unexpectedly. It has done this XX time(s). The following corrective action will be taken in 6000 milliseconds.

Restarting the service did nothing. Refreshing the schema did nothing. Installing the latest hotfixes did nothing and all of the other MAs were operating normally. No other errors are being logged and there is nothing in the SQL Server logs either. Frustrating!

Luckily, clearing the connector space seemed to address the issue. I wish I would write why or what caused the issue, but I can tell you that is what fixed it -- at least for me. If you are reading this because you came across the same issue, I am hoping it will fix it for you as well.

Looking in Event Viewer, the following 7031 Service Control Manager error event is recorded

Hiding the Display of Domain Information in the FIM 2010 Password Reset Portal

2012-08-02T16:59:00Z

One of the features of FIM 2010 R2 is that the password reset portal is now anonymously accessible; therefore, extranet – including even internet – users can register and reset their passwords from a non-domain joined machine. If I am not mistaken, this was one of the most requested enhancements to the product and its inclusion in in R2 is huge.

On one of my current projects, we are establishing a gateway environment which will host UAG published applications with which the general public and government employees can collaborate and exchange information. To facilitate the IdM components of this (e.g. the request for new accounts, etc.), we are leveraging FIM 2010 R2 and are publishing both the Password Reset portal to the internet.

Anyway, in using the SSPR portals in this manner, there is one security related issue to which the government understandably objects; the portal displays of the domain name of the authenticated user account. For non-Public Sector folks, exposing the name of the domain is a security no-no

See below (the actual domain name has been redacted):

At first, we tried to parse out the exposure domain name through use of UAG AppWrapper functionality; however, for some reason that only the product team can explain, if you tamper with the displayed domain name value on that form, it breaks the ability for users to register.

Luckily, we found an acceptable work around. You can suppress the (logged in as: DOMAIN\USER) line entirely in its CSS. Here where you do it:

1.       Open up the Registration.css style sheet located in Program Files\Microsoft Forefront Identity Manager\2010\Password Registration Portal\css
2.       Scroll down to the rule: .registrationGatewayContainerDiv span div span i
3.       Change its display declaration value from block to none (i.e. display:block -> display:none)
4.       Save the file.
5.       Open the portal and you ought to see:

That is all what is necessary. Unfortunately though, this only hides the block from being rendered in the browser; the HTTP response is still returning the(logged in as: DOMAIN\USER) line in its HTML.

But unfortunately, this is all what can be done at this point.

Good luck…