One of the typical things of a webapp deployed on IIS is that everyday the first visitor has a very slow loading page. This is due to the application pool recycling. Every night, somewhere between 2 and 4 (for default installs) the application pools are recycled. After this when the first visitor arrives certain code is loaded again which takes some time. Consequent visitors don’t suffer this phenomena.

In the IIS world there’s a known solution for this: "IIS Warm Up scripts”. There even was  a built-in module for this in IIS 7.5, however it was in beta state and currently has been removed from the web. With some PowerShell and Scheduled Task magic we can warm up IIS just as good. In my example the first user was experiencing a 15-20 seconds delay before the FIM Portal showed up. After applying the following solution that was more like 2 seconds.

Our script which will warm up the site will do this every time the application pool is recycled. The trigger for the scheduled task will be an event in the Application event log. Therefor we have to modify the default settings of the application pool so that it logs these events.

Open the IIS management console and locate the application pool responsible for the SharePoint site hosting your FIM portal

Righ-click and choose advanced settings, make sure to set “Specific Time” to True.

Every time the application pool is recycled by the schedule defined in the “Specific Times” array the following even will be logged:

A worker process with process id of '4420' serving application pool 'SharePoint - 80' has requested a recycle because it reached its scheduled recycle time.

Now the following script can be executed to warm up IIS. It will do this by visiting the page and performing a get. It’s very basic and probably can be improved or rewritten.

function get-webpageWithAuthN([string]$url,[System.Net.NetworkCredential]$cred=$null){
    write-host -foregroundcolor green "Warming up $url";
    $wc = new-object net.webclient;
    $wc.credentials = $cred;
    #$wc.Headers.Add("user-agent", "PowerShell");
    $html = $wc.DownloadString($url);
    #$html
}

#FIM
$website = http://FIM.setspn.blogspot.com/IdentityManagement
$credentials = [System.Net.CredentialCache]::DefaultCredentials;
get-webpageWithAuthN -url $website -cred $credentials

Now we can create the Scheduled Task. I choose to run it as “local system”. This seems enough to warm up the portal. I think because this way the FIM Service is queried to see if “Local System” (my FIM server itself) is known in the portal. Obviously this is not the case and I will probably see a “Service not available” error. But the point is that the Portal is warmed up!

We will add some triggers:

• Type: On an event
• Log: System
• Source: WAS
• Resource ID: 5076

Then we will specify an action:

• Action: Start a program
• Program/Script: PowerShell.exe
• Add arguments: c:\yourfolder\script.ps1
• Start in: c:\yourfolder

If we also want to trigger the script when we an administrator recycles an Application Pool we have to add a trigger for event 5079 (System –> WAS: 5079)

If we also want to trigger the script when we perform an IISreset we can add a trigger for the following event 3201 (System > IIS-IISREeset: 3201)

Obviously this way of working could be applied for other websites too.

Lately I helped a colleague setting up a TMG array. The TMG nodes were in a workgroup in the DMZ. In the LAN there was a domain-joined EMS server. As there was a firewall between DMZ-LAN we had to open up some ports. The TMG documentation is pretty good, but I couldn’t find any documentation regarding the firewall ports…

So here is a table I built by setting up a DC, EMS, TMG and a m0n0wall virtual firewall appliance in my personal lab. I like m0n0wall as it comes with an easy web interface. It also has logging which you can activate on a per rule base. Here are some screenshots:

Firewall rules:

Logging:

 

And finally the result of all my hard work:

 

Some remarks:

• RPC from TMG –> EMS doesn’t seems necessary. I was able to open the MMC on both the EMS and the TMG node.
• RPC from EMS –> TMG starts off at port 10.000. All though windows 2008 (&R2) officially start off at 49152, there are some server products which modify this. Think TMG, Think Exchange. (The default dynamic port range for TCP/IP has changed in Windows Vista and in Windows Server 2008)
• EMS –> TMG port 445 was necessary for remote diagnostic logging. I’m still looking into as why I can’t view the logging remotely. I can enable/disable it though…

Performing a configuration migration is pretty straight forward. You just have to pay attention to some things. Besides the excellent guide (Configuration Migration Deployment Guide ) I also pay attention to the following points:

1. FIM MA health

This is a rather nasty one. However if you fail to detect it, and you happen to migrate your configuration to a FIM MA in this situation you’ll be doomed to a do a rollback using SQL backup-restore. The good news it’s easy to detect. Every time you perform modifications to your MA’s or MV configuration, this info get’s replicated to the FIM Service. You can see this info below administration > all resources:

Every time such an update occurs, requests are logged in the FIM requests log:

That’s also one of the reason why running a Full Synchronization profile on your FIM MA very often is a bad idea. This data gets replicated to the FIM Service every time you do a full sync on your FIM MA. This is the easiest way to make your FIM Service DB explode in size. But, back on track now. Using the following WMI trickery (discovered by Craig Martin): MSDN: MIIS_ManagementAgent Class

You can force this replication to occur by executing the following statements:

### Get the FIM MA
$fimMa = Get-WmiObject -Class MIIS_ManagementAgent -Namespace root/MicrosoftIdentityIntegrationServer -Filter ("Type='Forefront Identity Management (FIM)'")
### Call the WMI method to ReSync the Config Objects from miiserver.exe to microsoft.resourcemanagement.service.exe$fimMa.ResyncSyncConfigObjects()
$fimMa.ResyncSyncConfigObjects()

Now what should the outcome look like?

The ReturnValue Success is a good start. You also should see the requests being logged. However, if you see the following entry in your application log you got some work to do:

In words:

A update on the configuration of a MA or MV failed to replicate to a target connector directory that is capable  of storing MA/MV configurations.  As a result, the MA/MV configuration data in this connector directory is not up to date.  Please correct the condition that causes the error, and triggers a resync by updating the password information of the target MA.
Additional information:
Error Code: 0x80230709
Error Message: (The extension operation aborted due to an internal error in FIM Synchronization Service.)
Operation: Clean up MAs
Name of the MA to replicate: 
Guid of the MA to replicate: 
Name of the target MA: FIM MA
Guid of the target MA: {35F6A1E2-CCF6-4C8A-91FF-2114625B144D}

I haven’t found a nice workaround just yet… What I’ve done successfully in the past:

1. delete the FIM MA (CS and MA itself)
2. wipe the MV
3. Reconfigure the FIM MA from scratch or by importing an earlier (healthy?) FIM MA xml.
4. Import, join and sync in the proper order

This might seem like a lot of pain, and it sure it. But I prefer avoiding even worse: having a setup which refuses to recognize it’s declarative SR’s.

2. MA Schema Up-to-dateness

Very short tip: before you start exporting/importing, make sure your schema’s of your MA’s are up to date. Doing an update schema on each MA is a quick & easy test. This way you can avoid some additional trickery. It shouldn’t break anything, but it might give you all sorts of weird issues.

3. Attribute Precedence

Make sure to double check your attribute precedence. If you have declarative rules and classic rules (which the FIM MA always does), you might have to toy around with the attribute precedence. As this might get scrambled due to the order the MV gets the contribution info.

This is in fact a double post. I posted this article to the TechNet Wiki for which I originally wrote this article. Link: TechNet Wiki: FIM 2010: Understanding Kerberos Authentication Setup

The goal of this article is to provide some background information regarding the Kerberos related configuration steps of the FIM Portal and FIM Service. The article has been written in such a way so that most of the points can in fact be used for any application requiring Kerberos.

This article will not discuss the various possible FIM Topologies. All information should be valid regardless whether all roles are combined on a single server or split across multiple servers.

Throughout the article a demo domain will be used. The domain which will be referenced as an example is contoso.com (NetBIOS name: CONTOSO).

Table of Content:

1. Identify Services
2. Identify Service Identities
3. Name Services
4. Configure DNS
5. Configure Service Principal Names (SPN's)
6. Configure IIS for Kerberos
7. Identify Delegation Requirements
8. Configure Delegation
9. Enforce Kerberos (FIM Specific)

1. Identify Services top

Before we can start configuring SPN’s (Service Principal Names) we have to determine what services we want to enable for Kerberos authentication. A typical FIM Portal deployment has the following services:

• Database for the FIM Service (SQL Service)
• FIM Service
• FIM Portal (Windows Sharepoint Services (WSS))

Note
In the above overview we’re leaving the FIM Synchronization Service and the databases for the WSS aside. They don’t bring any added value to this article.

The following picture provides an overview of these services.

2. Identify Service Identities top

Kerberos is all about authenticating principals to a service. Each principal is represented by an account in AD. This can either be a computer or a user account. Before Kerberos can take place, each service should be represented by an account in AD. Again this can either be a computer or a user account. Therefore it’s important to determine which account represents a given service.

Note
A typical Windows Service has its identity configured in the Services MMC. A website however has its identity configured in the IIS Management Console (below the Application Pools section)

The list below provides an overview of our services and their associated identities.

• Database for the FIM Service: the user account running the sqlservr.exe process of the SQL Instance hosting that database
• FIM Service: the user account running the FIM Service service
• FIM Portal: Application Pool identity in IIS for the FIM Portal site

This information is displayed in the following picture.

3. Name Services top

Besides the principal representing a service, we also need to determine a name to access the service. Choosing names can be rather important when actual people are involved. Check the following examples:

1. The FIM Service is configured to access its database on SPRDL2FIMSQL01B.contoso.com
2. Users visit the FIM Portal by browsing to SPRDL3FIMPOR01.contoso.com

The first one is in fact not a problem at all. Nobody will mind that a name, for which IT probably has an explanation, is configured for a service to use. In the second example your users will by no means be able to remember the URL. Something like fimportal.contoso.com is way more feasible.

Important
Choose your service names carefully and always keep in mind whether end-users will use them.

In the picture above several client-server communication arrows have been pictured. In our example we will go with the following names to access the services:

1. Database for the FIM Service: fimsql.contoso.com
2. FIM Service: fimsvc.contoso.com
3. FIM Portal: fimportal.contoso.com

Note
There’s nothing wrong with choosing the actual server name of the SQL server to associate with your SQL service.

4. Configure DNS top

Clients have to be able to resolve the names for these services. We can register these records in DNS. It might seem convenient to use an alias (CNAME) record for some of the services. However this is a bad idea as explained in the following paragraph.

Using a CNAME record would ensure that updating the server its IP has no influence on the service name record. However CNAME records resolve in another way than A records. A client requesting a Kerberos ticket for a given service will ask AD a ticket for whatever the name resolves to. This is how a client will resolve those names:

• fimsvc.contoso.com (CNAME) -> server01.contoso.com -> IP_of_FIM_Server
• fimsvc.contoso.com (A) -> IP_of_FIM_Server

In bold the names are shown for which a Kerberos authentication attempt will be performed. In the first example you can clearly see that our client will request a Kerberos ticket for the wrong service as our service is coupled to fimsvc.contoso.com. So things will go wrong. For more information check Kerberos Basic Troubleshooting: Tip 3: SPNS and CNAME Records

Important
Register A records to ensure the correct service name is used in the Kerberos authentication attempt

5. Configure Service Principal Names (SPN's) top

So we got a name and an identity for our service. How do we tell AD that these belong together? Ahah! Now we get to the Service Principal Names (SPN's). Whenever someone wants to use Kerberos to authenticate to a given service, they contact the Key Distribution Centre (KDC) and ask for a service ticket. The KDC is running on each domain controller. It knows which ticket to hand out because the client specified the service it wants a ticket for. The service was in fact specified by its name. More particularly by using the Service Principal Name (SPN).

An SPN is based upon the following format <service>/<fqdn>:<port>

In our example we will execute the following commands:

• Setspn –S MSSQLsvc/fimsql.contoso.com:1433 sa_sqlsvc
• Setspn –S MSSQLsvc/fimsql:1433 sa_sqlsvc
• Setspn –S FIMService/fimsvc.contoso.com sa_fimsvc
• Setspn –S FIMService/fimsvc sa_fimsvc
• Setspn –S HTTP/fimportal.contoso.com sa_wss
• Setspn –S HTTP/fimportal sa_wss

Important
Never register a given service (<service>/<fqdn>:<port>) on multiple accounts. Whenever multiple accounts are responsible for the same service, AD cannot determine which account to use to hand out the Kerberos service ticket. As such Kerberos authentication breaks. This issue is called Duplicate SPNs. You can do a quick check in your domain for duplicate SPN's by executing Setspn -X.

Important
Always register both short and long (domain fqdn) for a service. This will ensure Kerberos is available at all times.

Important
SQL always requires an SPN of the format MSSQLsvc/<fqdn>:<port>, even when using the default (1433) port. If your port is dynamic you have to configure it to be static or give the SQL Server service account permissions to update its own SPN's.

Note
A lot of guides will tell you to use Setspn –A instead of setspn –S. The advantage of using the –S option is that it will check the domain prior to adding the SPN. This will avoid setting duplicate SPNs.

6. Configure IIS for Kerberos top

When the above steps have been implemented, both the FIM Service and SQL will start accepting Kerberos. However IIS is slightly different. In fact skipping this particular step will often break your configuration all together. One of the symptoms when having a bad Kerberos implementation is the following: you type the URL of your website, you get presented with an authentication prompt, and no matter how many times you correctly enter your credentials, you keep getting prompted over and over again.

This issue occurs because by default IIS uses the account of the server to validate service tickets instead of the Application Pool identity. We can force IIS to use the identity of the application pool by configuring this in the applicationHost.config configuration file.

Important
The applicationHost.config is typically located in c:\windows\system32\inetsrv\config\ Remember to take a backup when modifying this file.

The following steps are required to configure Kerberos Authentication to work with a custom Application Pool Identity.

Launch an elevated command prompt and execute the following commands: cd c:\Windows\System32\inetsrv\config copy applicationHost.config applicationHost.config.dateOfToday.bak notepad applicationHost.config Search for windowsAuthentication enabled="true" if you are below: <location path="SharePoint - 80"> The above might actually be different in your environment. You need to locate the path of the IIS site which represent your FIM Portal WSS site. Add useAppPoolCredentials="true" so the line looks like: <windowsAuthentication enabled="true" useAppPoolCredentials="true"> Save the file and exit notepad Execute the following command: iisreset

7. Identify Delegation Requirements top

Now that we got Kerberos authentication working for all of the involved services we have to determine whether additional configuration is required. Sometimes it’s obvious that Kerberos delegation has to be configured, sometimes it’s less obvious. Either way, it’s advised to check the product specific documentation to be sure. Kerberos delegation will allow a service to impersonate a visiting user and authenticate to another service as if it were the user himself who visits that service.

From the FIM Installation Guide we know that the following delegation scenarios are required:

1. FIM Portal to FIM Service
2. FIM Service to FIM Service

This is explained in the "Establish SPNs for FIM 2010" section of the installation guide.

8. Configure Delegation top

To allow a given service to delegate to an other service, we have to configure delegation on the service its service account to the delegated service its SPN. Delegation can be configured using Active Directory Users & Computers (ADUC). As explained in the previous section we have to configure the following delegation scenario's:

For the Portal to be able to delegate to the FIM Service we would have to:

1. Open ADUC and locate the service account for the Portal (sa_wss)
2. Open the properties of sa_wss and choose the delegation tab
3. Check Trust this user for delegation to the specified services only
4. Check Use Kerberos only
5. Click Add...
6. Click users or Computers...
7. Type the name of your FIM Service service account: sa_fimsvc
8. Click Check Names and Click Ok
9. Select the FIMService entry and Click Ok
10. Click Ok to close the account properties

Some screenshots to aid in the process: FIMService selection screen

And the resulting Delegation tab for the sa_wss acocunt:

For the FIM Service to be able to delegate to the FIM Service we would have to:

1. Open ADUC and locate the service account for the Portal (sa_fimsvc)
2. Open the properties of sa_fimsvc and choose the delegation tab
3. Check Trust this user for delegation to the specified services only
4. Check Use Kerberos only
5. Click Add...
6. Click users or Computers...
7. Type the name of your FIM Service service account: sa_fimsvc
8. Click Check Names and Click Ok
9. Select the FIMService entry and Click Ok
10. Click Ok to close the account properties

 

Note
The delegation tab on a user is only visible when an SPN has been registered for that account.

Note
The above procedure assumes your domain is in 2003 DFL or higher. Windows 2000 DFL only has unconstrained delegation available.

9. Enforce Kerberos (FIM Specific) top

Optionally you can configure the FIM Portal to only accept Kerberos. This is explained in the FIM Installation Guide  > Installing The FIM 2010 Server Components > Activating The Kerberos Protocol Only (link)

The following steps are required to force Kerberos Authentication for the FIM Portal.

Launch an elevated command prompt and execute the following commands: cd c:\inetpub\wwwroot\wss\VirtualDirectories\80 copy web.config web.config.dateOfToday.bak notepad web.config The above might actually be different in your environment. You need to locate the path of the IIS site which represent your FIM Portal WSS site. Locate the element <resourceManagementClient . . . /> Add requireKerberos=”true” so that it reads <resourceManagementClient requireKerberos="true" . . . /> Save the file and exit notepad Execute the following command: iisreset

Happy Kerberizing

Active Directory Topology Diagrammer (ADTD) has been updated! ADTD has been out there for ages and has proven to be useful many times. The UI is very similar to the original one. The DFS-R tab was added to allow DFS-R topologies to be discovered. Exchange 20xx support was added. I did a discover & draw and it seemed to discover everything just nice. Something they added (if I’m not mistaken, please correct me if I’m wrong) is the Exchange schema version on the domain Visio. The Exchange discovery works fine too, however in our environment it failed to draw the number of mailboxes. It seems to draw the amount of mailbox one Exchange 2007 fine (we have some left). But for 2010 it displays 0… The SMTP connectors were drawn perfectly. Definitely a must-have tool for documentation purposes or just to discover anomalies.

You can download ADTD from here: Microsoft Active Directory Topology Diagrammer

Thanks to Mark Parris for the tip at ActiveDir.org

The main dialog:

A small part of the domain visio:

I’m currently involved in a project where FIM will be used by end-users which will perform some limited management tasks in the portal. One of the remarks we got is that the “Welcome John Doe” button in the upper right corner is not good. To be more specific, if a user clicks it, they get redirected to pages which are irrelevant for FIM. This comes from the Windows Sharepoint Serivces framework which hosts the FIM Portal. In fact it has nothing to do with the FIM Portal experience.

In detail:

If you click it:

To modify (hide) this button we don’t have to “hack” standard WSS pages. Tampering with the .aspx pages which the SharePoint installer provides is probably not supported anyway.  However we can simply modify the CSS code which is responsible for styling this part of the Portal. Quick Tip: using IE8/9 (and perhaps 7 too) you can press F12 when visiting the portal. By using the mouse button in the upper left corner you can then select a given part of a site and it will show you the CSS code which is active. You can even modify the CSS over there to test the possible outcome. Modifying the CSS is a supported way to brand the Portal according to your company image. Here’s an excellent guide on the subject: Introduction to Configuring and Customizing the FIM Portal

From the above we can clearly see that if we’d modify the “.ms-globalbreadcrumb” section, we could alter the behavior of the section containing the welcome button. It’s enough to add “display:none” in order to hide the upper item.

I think the default theme is located in c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\THEMES\FIM. But I would definitely advise against editing these files. Or you keep the original ones in a safe place (copy/rename) or you create a copy of the FIM theme and start customizing the copy. After switching the theme on and off (by selecting an other temporary theme) , and by running an IISReset, the result will look like this:

Whilst the button is there, it should be hidden. Now try to click it! :p

P.S. If you want to change the theme afterwards, or other settings from SharePoint, it might be convenient to note down the following URL: http://yourportal.domain.tld/IdentityManagement/_layouts/settings.aspx This will bring you to the landing page of the “settings” button. As this button is also displayed on that upper item…

One of the challenges of applying hotfixes to a distributed application is the order in which you apply them. We have an Active FIM Synchronization Service, and a cold standby. I will leave out the FIM Portal/FIM Service instance. Today we did the upgrade of our lab from FIM 2010 build 4.0.3531.2 (Update 1) to the latest available build: 4.0.3576.2.

I would suspect the order to be something like this:

1. Stop Active FIM Synchronization Service
2. Update the Active FIM Synchronization Service bits
3. Stop Active FIM Synchronization Service (+ disable for safety)
4. Enable Passive FIM Synchronization Service
5. Run MIISActivate
6. Stop “Passive” FIM Synchronization Service
7. Update the “Passive” FIM Synchronization Service bits
8. Stop & Disable FIM Synchronization Service
9. Fall back using MIISActivate again

However when running step 5 we were confronted with two popups: one stating “everything is ok”, followed by one giving the following error code: 0x80230453. A quick google gave no results, and that’s why I’m putting this post here. It might make sense as to why the activation command does not run, after all it’s using old binaries against an updated database…

So here is the order which worked out fine for us:

1. Stop Active FIM Synchronization Service
2. Update the Active FIM Synchronization Service bits
3. Stop Active FIM Synchronization Service (+ disable for safety)
4. Enable Passive FIM Synchronization Service
5. Update the “Passive” FIM Synchronization Service bits
6. Run MIISActivate, test FIM Sync
7. Stop & Disable FIM Synchronization Service
8. Fall back using MIISActivate again