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

On Henrik Nilson’s blog I found a link to a session from Tech-Ed: Technical Overview of Microsoft Forefront Identity Manager 2010 R2 It’s definitely worth watching. If you’re in a hurry though, here’s a brief summary:

• Support for Extranet Password Reset (other browsers/platforms, not domain-joined)
• Reporting: group membership and object change history
• Extensible MA framework
• Performance improvements
• Best Practices Analyzer
• Add-in Support for Outlook 2010 x86 & x64
• Support for SharePoint 2010

Password Reset

Very neat: support for password resets from PC’s which are not joined to the domain! So this means the extranet password reset scenario is added to FIM 2010 R2! And because no fancy ActiveX is used this should work just fine from other browsers/platforms as well.

This extranet scenario is made available through a new ASP.net password registration/reset portal. This portal is not based upon Sharepoint. They also added the option to add an additional Q/A gate for people resetting their password externally. You could see these as coming from an untrusted location and requiring to answer more questions than someone doing it from on your corporate LAN.

Reporting

This functionality will be made available through a custom FIM MP for SCSM. The SCSM data warehouse is a requirement. If you don’t have one, you’ll be allowed to use one without additional licensing costs.

Extensible MA Framework

Outlook 2010 & Sharepoint 2010 support

Introduction

Lately a colleague of mine was struggling with the following: he wanted a script to be ran from within a Startup Script GPO. Now the problem he was encountering was the following Security Warning from PowerShell:

In words:

Security Warning
Run only scripts that you trust. While scripts from the Internet can be useful, this script can potentially harm your
computer. Do you want to run \\file.setspn.com\scripts\script.ps1?
[D] Do not run  [R] Run once  [S] Suspend  [?] Help (default is "D"):

Now if you have to run something like this occasionally, you can type R and get on it with it. However if this is a script which has to automatically run at startup, this will be a showstopper. So here is some additional information on how to avoid these warnings.

I didn’t tested this in the context of a computer starting up and executing such a script. I just tested this from the Administrator point of view: you run a PowerShell script from a share and you want to avoid that warning. Now what? I will briefly explain Execution Policies and Execution Policy Scopes before actually presenting a solution.

PowerShell Execution Policies

As most of us know by now, PowerShell comes with an execution policy. This policy define which scripts can ran and from which location. By default it’s configured to restricted:

In words:

File \\file.setspn.com\scripts\script.ps1 cannot be loaded because the execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:37
+ \\file.setspn.com\scripts\script.ps1 <<<<
    + CategoryInfo          : NotSpecified: (:) [], PSSecurityException
    + FullyQualifiedErrorId : RuntimeException

However we can easily change the policy to one of the following options:

• Restricted: no scripts
• AllSigned: only signed scripts
• RemoteSigned: local [+detected as local intranet] scripts and signed scripts remotely
• Unrestricted: all scripts but comes with warnings when running from a share
• Bypass: all scripts, no warnings

If you want a full explanation on each of these policies, check TechNet: about_Execution_Policies

PowerShell Execution Policy Scope

Now if you changed the above policy using the Set-ExecutionPolicy Policy command, you changed it for everyone running PowerShell scripts on the current machine. Did you know there is an alternative? You can actually specify a scope using the –scope parameter! This can come in very handy when you just want to open up PowerShell temporary for the installation of a product. The following scopes exist:

• Process: affects only the current PowerShell session
• CurrentUser: affects only the current user
• LocalMachine: affects all users on the current computer

If you want a full explanation on each of these scopes, check TechNet: about_Execution_Policies There’s also additional info available if you want to control this by using GPO.

Determing The Active PowerShell Execution Policy

Using the Get-ExecutionPolicy command you can get the current policy, however if you add the –list parameter you can see where it’s coming from:

Now after running Set-ExecutionPolicy –Scope Process Unrestricted

Now the advantage is that whenever this PowerShell session is closed, the overall policy remains to what is was before my modification.

Getting Rid Of the Warning

All of the options below will explain how you can get rid of the warning when execution a script from an UNC path. Between [] I’ve added the PowerShell execution policies this is working with. The PowerShell script I’m running is located on \\file.setspn.com\scripts and it only contains one line: “write-host –forefgroundcolor green “script executed successfully””.

Option 1: use a shortname in the path [RemoteSigned/Unrestricted]

Why does this work?

By default IE7 and up are configured to automatically detect intranet network. This one checkbox actually is equivalent to checking the 3 options below it. Because we use a UNC path with a short name (\\file), it’s detected as an Intranet and hence no warning is displayed. However once you use a FQDN (\\file.setspn.com), this detection does not work. Reference: Enabling "Automatically Detect Intranet Network" on a domain member computer will enable all the three Intranet Options automatically.

Do we like this? I don’t. I hate NetBIOS names. On to the next option

Option 2: Specify Local Intranet Sites [RemoteSigned/Unrestricted]

The security warning only comes up when the script is ran from an untrusted location, we can add the UNC path to the local intranet. We can do this using one of the following formats:

1. \\*.setspn.com
2. file://*.setspn.com
3. \\file.setspn.com
4. file://file.setspn.com
5. *.setspn.com
6. file.setspn.com

The first 4 options will only affect files accessed from UNC paths, however option 5 & 6 will also involve HTTP/HTTPs traffic. Option 1 & 2 are in fact the same. The same goes for option 3 & 4. Whenever you enter an UNC path like \\location it will automatically be converted to file://location by IE. After adding \\*.setspn.com:

The script now runs just fine:

Option 3: Copy The Script Locally [RemoteSigned/Resctricted]

Obviously this is not applicable in certain scenario’s, but as a quick work around it’s a possibility.

Option 4: Sign your scripts [AllSigned/RemoteSigned/Resctricted]

Another possibility is to sign your scripts. A detailed guide is out of the scope of this post, a good description of the process can be found here: Scott Hanselman: Signing PowerShell Scripts

Option 5: Use The Bypass ExecutionPolicy [Resctricted/AllSigned/RemoteSigned/Resctricted]

All of the above options (beside #1) require you to do some modifications. There’s also a way to just suppress these warnings: the Bypass exeuction policy! I think you can apply it in one of the following ways:

1. Set-ExecutionPolicy Bypass
2. Set-ExecutionPolicy Bypass –Scope Process
3. Powershell.exe –ExecutionPolicy Bypass –file \\file.setspn.com\script.ps1

Option 1 just doesn’t feel right. I myself would definitely go for option 2 or 3. They are more or less equivalent. Option 3 is ideally for calling a PowerShell script from within a bat file. Option 2 is just neat as it’s only active temporarily.

Conclusion

I’m not favoring one of the above options. I think PowerShell execution policies should be part of the Workstation/Server design. A given policy should be decided upon and pushed through GPO. Once that baseline is established, I would choose one of the above options to make a certain script work in the given scenario.

Like if RemoteSigned would be active on workstations, I would consider adding the UNC path to the Local Intranet sites. On the other hand if I would be administering servers (RemoteSigned active) and I’d have a script which I have to run just once, I would consider changing the execution policy to Bypass just for this PowerShell.exe instance (-scope process).

Happy PowerShelling!

One of the things a colleague of mine encountered in the past, and which I stumbled upon lately is the following. Sometimes people want to have the Local Administrator account disabled on their servers. There has been a GPO to do this for ages. It’s located below Computer Settings > Windows Settings > Security Settings > Local Policies > Security Options. The setting is “Accounts: Administrator Account Status”: Disabled.

The screenshot shown below is from the security policy on a server which has the policy (Administrator Status: disabled) applied. You can see that A group policy is setting the setting to enabled. Which is in fact the opposite of what I have configured through the GPO.

One could think I have another GPO being applied later. But using gpresult /H:report.html I can clearly see “my” GPO is winning and that the setting in fact should be set to disabled…

Also a regular Resultant Set Of Policy shows the setting as disabled…

But the account is Active and remains in this state…

So, Group Policy Preferences to the rescue! It’s not a real answer as to why things are going wrong, but it’s definitely a doable workaround. This policy works flawless.

You can’t always get to the bottom of things…

I’m not going to be explain something new today, but I’m just writing this article to explain how I established I was having this issue. Above that I want to make sure people find the explanation easier. This article references a PPT which has some great info on the issue.

It all started with a perfectly fine FIM deployment in a lab environment. One of the things we do from time to time is migrate the configuration to the Acceptance environment. To do this we use the FIM Configuration Migration scripts. After one of the migrations our User Edit RCDC in the Acceptance environment was broken. The RCDC defaulted to the Admin view and stated: There is an error in the synchronizationRule display configuration. Please contact your system administrator.

As I recently reviewed a RCDC troubleshooting article I knew what I had to do:

• Troubleshooting RCDC Configuration Issues Using FIM Portal Tracing

Make sure to change the level from “Error” to “Verbose”. This will give you the following entry in the event log:

In words:

The Resource Management Portal detected an error using the Resource Control Display Configuration (RCDC).  This prevented the portal from displaying the object as expected and the portal switched over to Admin View.

The failure is due to a incorrect configuration file.  The file does not validate against the configuration file schema.

Verify that the configuration file is valid XML and matches the configuration file schema. Either upload a new file or modify the existing file in the Resource Management Portal directory.  Afterward, reset IIS.

So now we get directed to an invalid RCDC XML. No worries: Craig Martin to the rescue: RCDC Troubleshooting He explains how you can use Visual Studio to validate the RCDC XML against the MS schema for RCDCs. The RCDC seemed fine. So eventually we logged a PSS case and got pointed to the following MS PPT:

• FIM Portal Troubleshooting - Default RCDCs Not Recognized After Replacement through FIM Service Configuration Migration.

The PPT is a must read. It clearly states how you end up in this situation and what to do to avoid it. For a fix, without having to wipe your database you’ll have to log a PSS case. The PSS people can give you a SQL procedure which can fix the guid of a given RCDC.

Related forums posts:

• Error in the synchronizationRule display configuration

P.S. Taking a backup from your FIM Service database is a not a luxury when migration configurations. Make sure you have that safety net available!

Again I’m posting with some FIM 2010 Update 1 issue. I’m not trying to make a statement regarding the stability of the FIM software, I’m just active in an instable environment . This error I received when trying to update a FIM 2010 Service and Portal Language Pack installation to Update 1.

The installer for Update 1 is a next next finish, but somewhere in the middle an application error occurs and the rollback is performed.

The error:

In words:

Microsoft.ResourceManagement.Setup.LanguagePack.Resource has stopped working.

I had absolutely no clue what the cause could be. I was logged on using a FIM Installer Account, so permissions should have been fine. On the list of todo’s for this environment I also had a WSS security hotfix. This is the hotfix I mentioned in WSS Killer Security Update. I prefer to install it in a controlled way instead of receiving it through WSUS. However installing the update didn’t work out. The setup just failed. The log files pointed me to: KB939308: Error message when you try to modify or to delete an alternate access mapping in Windows SharePoint Services 3.0: "An update conflict has occurred, and you must re-try this action"

After following the actions in that KB article, I reran the installer of the hotfix and everything worked out fine.

And guess what: the Language Pack Update 1 installer finished just fine too! I have no proof that they are related, but I ran the update multiple times, every time resulting in a crash. Once I cleared the cache of WSS as described in the article the update ran fine.

Happy updating!