Jorge 's Quest For Knowledge!

ILM/FIM Sync Engine Terminology

Jorge — Tue, 17 Aug 2010 20:29:00 GMT

The past week I delivered the FIM 2010 Foundation course that is made available by Oxford Computer Group. One of the things I noticed is that people struggle with all the terms and abbreviations. Because of that I promised my attendees to create a nice picture and include explanations. So here goes!

The picture below shows all possible actions that can be execute through one or more Run Profiles which have one or more steps.

MA = Management Agent

CS = Connector Space

MV = Metaverse

INBOUND ATTRIBUTE FLOW [1]: This flow is either caused by executing a Full Sync (touching all objects in the CS) or a Delta Sync (touching only changed objects in the CS) on a certain MA. This is the flow of data from a connector space object to a metaverse object. This only applies to CS objects that are in the same MA as for which the Run Profile was executed.

OUTBOUND ATTRIBUTE FLOW [2]: This flow is either caused by executing a Full Sync (touching all objects in the CS and corresponding MV objects) or a Delta Sync (touching only changed objects in the CS and corresponding MV objects) on a certain MA. This is the flow of data from a metaverse object to a connector space object in any affected MA. This applies to CS objects that are in the same MA as for which the Run Profile was executed and all other MAs that are affected by the inbound attribute flow from the MA as for which the Run Profile was executed.

PROJECTION [3]: This is the creation of a metaverse object based upon a connector space object when executing a Full Sync (touching all objects in the CS) or a Delta Sync (touching only changed objects in the CS). This only occurs when at least one projection rule has been configured in the MA and/or Sync Rule and when no joining rule was satisfied and when the connector filter in the MA is not met. This only applies to CS objects that are in the same MA as for which the Run Profile was executed. After projection, provisioning and inbound/outbound attribute flow may occur.

PROVISIONING [4]: This is the creation of a connector object based upon a metaverse object when executing a Full Sync (touching all objects in the CS and corresponding MV objects) or a Delta Sync (touching only changed objects in the CS and corresponding MV objects). This only occurs when provisioning is enabled in the metaverse and when either a Provisioning Rules Extension exists with provisioning code for one or more MAs or when an Outbound Sync Rule has been configured for one or more MAs with the option to create a resource in the target system. This only applies to MV objects that were "touched" because of the execution of Full/Delta Sync Run Profile on a certain MA.

JOINING [5]: This is the matching of connector space object with a metaverse object based upon certain (unique) identity data (e.g. employeeID) when executing a Full Sync (touching all objects in the CS) or a Delta Sync (touching only changed objects in the CS). This only occurs when at least one join rule has been configured in the MA and/or Sync Rule and when the connector filter in the MA is not met. This only applies to CS objects that are in the same MA as for which the Run Profile was executed. After joining, inbound/outbound attribute flow may occur.

IMPORT: This is the import of scoped data from a connected data source into the corresponding connector space. Either a Full Import or a Delta Import cam be performed. A Full Import just asks for all scoped data, whether or not it is new or has changed, and the sync engine determines new objects and/or changes by comparing it against existing CS objects. A Delta import asks the connected data source for the changes (assuming it can provide those) and the sync engine processes those changes.

EXPORT: This is the export of new/changed data (pending exports - adds, updates, deletes) from the connector space into the connected data source. Exports are always delta. Some connected data sources may want or expect a Full Export and it that case you would need to create your own MA for those connected data sources that expect it.

Cheers,

Jorge

--------------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test before implementing!
--------------------------------------------------------------------------------------------------
############### Jorge's Quest For Knowledge ###############
######## http://blogs.dirteam.com/blogs/jorge/default.aspx #########
--------------------------------------------------------------------------------------------------

Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 3)

Jorge — Thu, 12 Aug 2010 14:08:18 GMT

This post focusses on restoring the SYSVOL when replicated through the DFS-R mechanism. For the previous posts see here and here.

SYSVOL Replicated Through DFS-R - Authoritative Restore - Steps To Take

To perform an authoritative restore of the SYSVOL when using DFS-R, use the following steps:

Start the Registry Editor
Navigate to "HKLM\SYSTEM\CurrentControlSet\Services\DFSR"
Create a key called "Restore" (only time only)
Create a string value called "SYSVOL" (only time only)
For the string value called "SYSVOL" assign the value of authoritative
Navigate to "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore"
Create a key called "SystemStateRestore" (only time only)
Create a string value called "LastRestoreId" (only time only)
For the string value called "LastRestoreId" [1] assign the value of 10000000-0000-0000-0000-000000000000
Stop the DFSR Service
Start the DFSR Service

From the command-line the same can be achieved through:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore" /v SYSVOL /t REG_SZ /d "authoritative" /f
[1] REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\SystemStateRestore" /v LastRestoreId /t REG_SZ /d "10000000-0000-0000-0000-000000000000" /f
NET STOP DFSR
NET START DFSR

[1] When a backup application performs a system state restore, it must indicate that it has done so by setting the LastRestoreId registry value. The LastRestoreId is a GUID that is formatted as 00000000-0000-0000-0000-000000000000. The GUID has to be different each time a restore is requested. For example, if you have the LastRestoreId set as 10000000-0000-0000-0000-000000000000, for the next restore you have to set it to a different GUID, such as 20000000-0000-0000-0000-000000000000. For more information about setting LastRestoreId, see Registry Keys and Values for Backup and Restore.

As soon as the DFS-R Service starts, the following events appear with information about the non-authoritative restore.

Event ID 2109

Event ID 2110

Event ID 4106

Event ID 4108

SYSVOL Replicated Through DFS-R - Non-Authoritative Restore - Steps To Take

To perform a non-authoritative restore of the SYSVOL when using DFS-R, use the following steps:

Start the Registry Editor
Navigate to "HKLM\SYSTEM\CurrentControlSet\Services\DFSR"
Create a key called "Restore" (only time only)
Create a string value called "SYSVOL" (only time only)
For the string value called "SYSVOL" assign the value of non-authoritative
Navigate to "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore"
Create a key called "SystemStateRestore" (only time only)
Create a string value called "LastRestoreId" (only time only)
For the string value called "LastRestoreId" [1] assign the value of 10000000-0000-0000-0000-000000000000
Stop the DFSR Service
Start the DFSR Service

From the command-line the same can be achieved through:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Restore" /v SYSVOL /t REG_SZ /d "non-authoritative" /f
[1] REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\SystemStateRestore" /v LastRestoreId /t REG_SZ /d "10000000-0000-0000-0000-000000000000" /f
NET STOP DFSR
NET START DFSR

As soon as the DFS-R Service starts, the following events appear with information about the non-authoritative restore.

Event ID 2109

Event ID 2110

Event ID 4110

Event ID 4102

Event ID 4604

Cheers,

Jorge

Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 2)

Jorge — Thu, 12 Aug 2010 14:08:02 GMT

This post focusses on restoring the SYSVOL when replicated through the NTFRS mechanism. For the previous post see here and for the next post see here.

SYSVOL Replicated Through NTFRS - Authoritative Restore - Steps To Take

To perform an authoritative restore of the SYSVOL when using NTFRS, use the following steps:

Start the Registry Editor
Navigate to "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup"
Double-click on "BurFlags"
Assign it a value of D4 (hex) or 212 (dec)
Stop the NTFRS Service
Start the NTFRS Service

From the command-line the same can be achieved through:

REG ADD "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 212 /f
NET STOP NTFRS
NET START NTFRS

Also see Using the BurFlags registry key to reinitialize File Replication Service replica sets

As soon as the NTFRS Service starts, the following events appear with information about the non-authoritative restore.

Event ID 13566

Event ID 13553

Event ID 13554

Event ID 13516

SYSVOL Replicated Through NTFRS - Non-Authoritative Restore - Steps To Take

To perform a non-authoritative restore of the SYSVOL when using NTFRS, use the following steps:

Start the Registry Editor
Navigate to "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup"
Double-click on "BurFlags"
Assign it a value of D2 (hex) or 210 (dec)
Stop the NTFRS Service
Start the NTFRS Service

From the command-line the same can be achieved through:

REG ADD "HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup" /v BurFlags /t REG_DWORD /d 210 /f
NET STOP NTFRS
NET START NTFRS

Also see Using the BurFlags registry key to reinitialize File Replication Service replica sets

As soon as the NTFRS Service starts, the following events appear with information about the non-authoritative restore.

Event ID 13565

Event ID 13520

Event ID 13553

Event ID 13554

Event ID 13516

Cheers,

Jorge

Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 1)

Jorge — Thu, 12 Aug 2010 14:07:37 GMT

The SYSVOL contains logon scripts and GPOs for a particular AD domain. It replicates to all RWDCs and RODCs. When, during the promotion of the very first (W2K8/W2K8R2) RWDC, the DFL is configured with "Windows Server 2003" or lower, then the SYSVOL will use NTFRS as its replication mechanism. At a later stage when you increase the DFL to at least "Windows Server 2008", you can migrate the replication of the SYSVOL from NTFRS to DFS-R. The process for doing that is explained in the SYSVOL Replication Migration Guide: FRS to DFS Replication (Web Based) or SYSVOL Replication Migration Guide: FRS to DFS Replication (Word Doc).

If you need to migrate OTHER DFS NameSpaces from NTFRS to DFS-R then look at DFS Operations Guide: Migrating from FRS to DFS Replication and FRS to DFSR Migration Tool Released.

However, when, during the promotion of the very first (W2K8/W2K8R2) RWDC, the DFL is configured with at least "Windows Server 2008", then the SYSVOL will use DFS-R as its replication mechanism right away and no migration is needed to migration the replication of the SYSVOL from NTFRS to DFS-R.

The use of DFS-R, compared to NTFRS, is way better in terms of performance and stability. DFS-R also works better with RODCs than NTFRS. When the SYSVOL on an RODC is adjusted locally, the changes will remain and will not replicate out because the RODC does not support Outbound Replication to any DC. Over time, if you do this too often you will get inconsistencies. To resolve these consistencies you may need to do a non-authoritative restore of the SYSVOL when replicated by NTFRS. If the same occured on the RODC and DFS-R is being used as the replication mechanism for the SYSVOL, then the local change would be detected and reverted as if nothing had happen. This makes sure the SYSVOL contents remains consistent on RODCs. For other differences see The Case for Migrating SYSVOL to DFSR.

The availability of the SYSVOL is very important for users, because if it is not available on a certain DC (RWDC or RODC), both users and computers cannot log on using that DC.

For both replication mechanisms I will explain how to do an authoritative restore or a non-authoritative restore of the SYSVOL using either replication mechanism.

Authoritative Restore

With an authoritative restore, the data that's being restored is leading compared to all other versions of that same data on onther DCs. Taking that into account, when doing an authoritative restore on a RWDC, one should not forget that all other RWDCs and RODCs must do a non-authoritative restore.

Non-Authoritative Restore

With a non-authoritative restore, the data that's being restored or that is in place is not leading compared to all other versions of that same data on onther DCs. To get the most recent data, the DC for which a non-authoritative restore was done must get the most recent data from another DC.

For the post on restoring the SYSVOL when replicated through the NTFRS mechanism see here.

For the post on restoring the SYSVOL when replicated through the DFS-R mechanism see here.

Cheers,

Jorge

Speaking At TechED 2010? That's up to you!

Jorge — Mon, 09 Aug 2010 14:13:30 GMT

I have proposed to speak at TechED 2010 about the following: "DC Locator in AD for authN and SYSVOL/NETLOGON".

Please go to the following website and vote for my session called "Locating Domain Controllers for AuthN and SYSVOL/NETLOGON Access"

Website: http://europe.msteched.com/sessionpreference
Keyword to search for: LOCATING

Then click on the word ADD on the right of you screen.

THANKS!

Cheers,

Jorge

Speaking At TEC Europe 2010 In October

Jorge — Mon, 09 Aug 2010 13:56:48 GMT

Yes, it's that time of the year again! TEC 2010 EUROPE is coming and is planned for the first week of October 2010. This time you can find us in Dusseldorf. I'll be delivering one pre-conference workshops this year about disaster recovery together with Guido Grillenmeijer, Gil Kirkpatrick and Ulf "who's ya daddy" Simon-Weidner. The four of us are the "Masters of Disaster" :-)

In addition to that I'll be presenting about the DC Locator in AD for authN and SYSVOL/NETLOGON. From what I know right now, my session is scheduled on monday. There is a reason for it. Exactly one week later on October 11th we are expecting our new baby. We are hoping he/she comes a day earlier like Anne, so that his/her birthday will be: 10-10-10.

Information about the conference:

Event: The Experts Conference (TEC) 2010
Website: http://www.tec2010.com/
Location: Dusseldorf
Date: October 4th - 6th
Workshops: http://www.theexpertsconference.com/europe/agenda-speakers/pre-conference-workshops/
Agenda – TEC Directory/Identity: Not available yet
Agenda – TEC Exchange: Not available yet
Agenda – TEC Sharepoint: Not available yet
Sessions – TEC Directory/Identity: http://www.theexpertsconference.com/europe/agenda-speakers/directory-identity-training/session-abstracts/
Sessions – TEC Exchange: http://www.theexpertsconference.com/europe/agenda-speakers/exchange-training/session-abstracts/
Sessions – TEC Sharepoint: http://www.theexpertsconference.com/europe/agenda-speakers/sharepoint-training/session-abstracts/
Speakers – TEC Directory/Identity: http://www.theexpertsconference.com/europe/agenda-speakers/directory-identity-training/speaker-bios/
Speakers – TEC Exchange: http://www.theexpertsconference.com/europe/agenda-speakers/exchange-training/speaker-bios/
Speakers – TEC Sharepoint: http://www.theexpertsconference.com/europe/agenda-speakers/sharepoint-training/speaker-bios/

Make sure you are there and do not miss this!

Cheers,

Jorge

Auditing In Windows Server 2008 R2

Jorge — Fri, 30 Jul 2010 19:26:59 GMT

Auditing in Windows Server 2008 also provided granular audit policies, but those were only configurable locally on each server through the utility called AUDITPOL. From within a GPO you could only configure the global auditing policies. Windows Server 2008 R2 now also allows you to configure the granular audit policies through a GPO.

The Granular Audit Policies can be found in a GPO at the following location:

--> Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration

It contains the following node and subnodes:

Audit Policies
- Account Logon
  - Audit Credential Validation
  - Audit Kerberos Authentication Service
  - Audit Kerberos Service Ticket Operations
  - Audit Other Account Logon Events
- Account Management
  - Audit Application Group Management
  - Audit Computer Management
  - Audit Distribution Group Management
  - Audit Other Account Management Events
  - Audit Security Group Management
  - Audit User Account Management
- Detailed Tracking
  - Audit DPAPI Activity
  - Audit Process Creation
  - Audit Process Termination
  - Audit RPC Events
- DS Access
  - Audit Detailed Directory Service Replication
  - Audit Directory Service Access
  - Audit Directory Service Changes
  - Audit Directory Service Replication
- Logon/Logoff
  - Audit Account Lockout
  - Audit IPSec Extended Mode
  - Audit IPSec Main Mode
  - Audit IPSec Quick Mode
  - Audit Logoff
  - Audit Logon
  - Audit Network Policy Server
  - Audit Other Logon/Logoff Events
  - Audit Special Logon
- Object Access
  - Audit Application Generated
  - Audit Certification Services
  - Audit Detailed File Share
  - Audit File Share
  - Audit File System
  - Audit Filtering Platform Connection
  - Audit Filtering Platform Packet Drop
  - Audit Handle Manipulation
  - Audit Kernel Object
  - Audit Other Object Access Events
  - Audit Registry
  - Audit SAM
- Policy Change
  - Audit Audit Policy Change
  - Audit Authentication Policy Change
  - Audit Authorization Policy Change
  - Audit Filtering Platform Policy Change
  - Audit MPSSVC Rule-Level Policy Change
  - Audit Other Policy Change Events
- Privilege Use
  - Audit Non-Sensitive Privilege Use
  - Audit Sensitive Privilege Use
  - Audit Other Privilege Use Events
- System
  - Audit IPsec Driver
  - Audit Other System Events
  - Audit Security State Change
  - Audit Security System Extension
  - Audit System Integrity
- Global Object Access Auditing
  - File System (Global Object Access Auditing)
  - Registry (Global Object Access Auditing)

More detailed information about each auditing topic (including events) can be found:

Cheers,

Jorge

Managing The userAccountControl Attribute In AD By FIM

Jorge — Thu, 29 Jul 2010 21:02:46 GMT

If you are using some system manage Identities in AD and you are either using ILM 2007 FP1 or FIM 2010 you may need to configure the ILM/FIM Sync Engine to act on the AccountStatus value and translate that to the userAccountControl value in AD.

So...

If employeeStatus = 'Enabled' then the AD user account must be enabled, or in technical terms userAccountControl bit 1 (2nd bit) (2^1=2) must be disabled.

If employeeStatus = 'Disabled' then the AD user account must be disabled, or in technical terms userAccountControl bit 1 (2nd bit) (2^1=2) must be enabled.

If you want to do this using classic flow rules, then you need to the following:

The attribute "employeeStatus" must be available as a string attribute in the Metaverse. The attribute "userAccountControl" must be selected to be imported from AD.

In the AD MA you also need an advanced export attribute flow (MV:employeStatus --> CD:userAccountControl). For the flowrulename you can use anything you like. I prefer to make it as clear as possible to what happens, so I call it "generate-userAccountControl(CS)".

In the Rules Extension Project for the MA you need to add the following:

Imports ActiveDs <-- requires a reference added to the project!

Public Sub MapAttributesForExport(ByVal FlowRuleName As String, ByVal mventry As MVEntry, ByVal csentry As CSEntry) Implements IMASynchronization.MapAttributesForExport

Select Case FlowRuleName

Case "generate-userAccountControl(CS)"

If mventry("employeeStatus").IsPresent Then

Dim currentUACValue As Long

Dim newUACValue As Long

If csentry("userAccountControl").IsPresent Then

currentUACValue = csentry("userAccountControl").IntegerValue And (Not ADS_USER_FLAG.ADS_UF_PASSWD_NOTREQD)

Else

currentUACValue = ADS_USER_FLAG.ADS_UF_NORMAL_ACCOUNT And (Not ADS_USER_FLAG.ADS_UF_PASSWD_NOTREQD)

End If

Select Case mventry("employeeStatus").Value.ToLower

Case "enabled"

newUACValue = (currentUACValue Or ADS_USER_FLAG.ADS_UF_NORMAL_ACCOUNT) And (Not ADS_USER_FLAG.ADS_UF_ACCOUNTDISABLE)

Case "disabled"

newUACValue = currentUACValue Or ADS_USER_FLAG.ADS_UF_ACCOUNTDISABLE

End Select

csentry("userAccountControl").IntegerValue = newUACValue

End If

If you want to do this using declarative flow rules (Sync Rules), then you need to the following:

The attribute "employeeStatus" must be available as a string attribute in the Metaverse. The attribute "userAccountControl" must be selected to be imported from AD. The attribute "userAccountControl" must be available as a number attribute in the Metaverse.

In the Portal Portal you need an Inbound Sync Rule for the AD MA.

SOURCE = userAccountControl

TARGET = userAccountControl

In the Portal Portal you need an Outbound Sync Rule for the AD MA.

For the INITIAL FLOW in the outbound sync rule you can use the following:

SOURCE = IIF(Eq(employeeStatus,"Enabled"),512,514)

To make more readable...

    IIF(
        Eq(employeeStatus,"Enabled"),
        512,
        514
    )

TARGET = userAccountControl

For the PERSISTENT FLOW in the outbound sync rule you can use the following:

SOURCE = IIF(Eq(employeeStatus,"Enabled"),IIF(IsPresent(userAccountControl),BitAnd(33554397,userAccountControl),512),IIF(IsPresent(userAccountControl),BitOr(2,userAccountControl),514))

To make more readable...

    IIF(
            Eq(employeeStatus,"Enabled"),
            IIF(
                IsPresent(userAccountControl),
                BitAnd(33554397,userAccountControl),
                512

            ),
            IIF(
                IsPresent(userAccountControl),
                BitOr(2,userAccountControl),
                514
            )
    )

TARGET = userAccountControl

Cheers,

Jorge

Windows Server Core Configurator

Jorge — Thu, 29 Jul 2010 20:26:39 GMT

With Windows Server 2008, Microsoft introduced Server Core into the Windows Server operating system, which is a new installation option. Summarized: Windows Server WITH a GUI is Full Server and WIndows Server WITHOUT a GUI is Server Core. You could also call it "Windows without Windows" or "Windows Command Prompt".

Server Core has limited support for GUIs. Because of that a lot of the stuff locally must be done through Command Line Tools already in the operating system or third-party (free) tools. A non-exhaustive list of command line tools in Server Core can be found here.

Server Core is the perfect Windows Server option with the lowest attack surface you can imagine. Lots of the bagage that Full Server has is not available. If it is not available there's not much left to attack.

Although perfect in terms of security, admins may not feel that well because they do not always know all the required command line utilities with their options to do something on the server.

A while ago, the Server Core Configurator was born which allowed an admin to use a GUI to do stuff locally on Server Core. The story about that tool can be found here. Unfortunately that tool is not available anymore to download. So, what are the options now?

On codeplex you will find two versions of Windows Server Core Configurator. Version 1.1 can be used on Windows Server 2008 Server Core (x86 and x64) and on Windows Server 2008 R2 Server Core (x64 only) because it is based upon VB Script. Version 2.0 can only be used on Windows Server 2008 R2 Server Core (x64 only) because it leverages PowerShell. The required features are "NetFx-ServerCore Feature" and "PowerShell" and both are only available on the Server Core version of Windows Server 2008 R2. As soon as you start version 2.0 it checks for the required features. If those are not installed, then those will be installed. If you are using Server Core on Windows Server 2008 R2, I really suggest you use version 2.0 of the Windows Server Core Configurator. The GUI is amazing!

Have a look at some screenshots for both versions.

"Windows Server Core Configurator Version 1.1"

"Windows Server Core Configurator Version 2.0"

Isn't this just COOL?!

Cheers,

Jorge

Configuring Sharepoint 2010 To Use ADFS v2 As An Authentication Provider

Jorge — Mon, 05 Jul 2010 20:40:35 GMT

I have started playing with ADFSv2 and I'm trying to configure Sharepoint 2010 to use ADFSv2 as an authN provider. I found the following links to get this done. I don't feel like searching for this again and because of that I decided to blog the links for future references.

Cheers,

Jorge

ADFSv2 Video By Matt Steele

Jorge — Sun, 04 Jul 2010 08:54:17 GMT

I just started diving into ADFS and its inner workings. I also found this great video by Matt Steele where he, in an easy way, explains at a high-level what ADFS can do for you and how it works in combination with Windows Azure.

See it here.

Cheers,

Jorge

Windows Sharepoint Services 3.0 Breaks After Installing Update MS-KBQ983444

Jorge — Mon, 28 Jun 2010 15:54:21 GMT

In my personal FIM test environment I have not had any issues with update MS-KBQ983444 (MS10-039: Description of the security update for Windows SharePoint Services 3.0: June 8, 2010). However, at my customer I have experienced issues twice (different environments) after this update was installed.

One day the FIM Portal is working perfectly and you do not experience any issues. Everything is working fine. Suddenly the next day or a few days later, when you navigate to the FIM Portal you get an error as if the URL does not exist. Weird! After checking all kinds of stuff you find nothing is wrong and everything is as it needs to be.

After opening the event viewer, you may see errors similar to what you see in the pictures below:

If you see through Windows Update (Windows Update --> View Update History) that the update MS-KBQ983444 was installed recently you can almost be certain that it is not a FIM related issue, but rather a Windows Sharepoint Services (WSS) related issue.

On the FIM Portal Server(s) experiencing these I performed the following steps to solve this:

Open administrative command prompt windows
Navigate to "%COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin"
Execute the following command: "psconfig -cmd upgrade -inplace b2b -wait -force"

You may see similar output as shown in the following picture

Now try to access the FIM Portal again and everything should be OK again.

More related information:

Cheers,

Jorge

.NET Verification Tool

Jorge — Mon, 28 Jun 2010 14:11:31 GMT

FIM 2010 and a lot of other apps use some kind of version of .NET Framework. If you want to check the health and status of the .NET Framework version(s) you have installed, then you can use the .NET Framework Verification Tool.

SOURCE: http://blogs.msdn.com/b/astebner/archive/2008/10/13/8999004.aspx

=============================================================================================

.NET Framework Setup Verification Tool User's Guide

Introduction

This .NET Framework setup verification tool is designed to automatically perform a set of steps to verify the installation state of one or more versions of the .NET Framework on a computer. It will verify the presence of files, directories, registry keys and values for the .NET Framework. It will also verify that simple applications that use the .NET Framework can be run correctly.

Download location

The .NET Framework setup verification tool is available for download at the following locations:

REMARK: The .zip file that contains the tool also contains a file named history.txt that lists when the most recent version of the tool was published and what changes have been made to the tool over time.

Supported products

The .NET Framework setup verification tool supports removing the following products:

.NET Framework 1.0
.NET Framework 1.1
.NET Framework 1.1 SP1
.NET Framework 2.0
.NET Framework 2.0 SP1
.NET Framework 2.0 SP2
.NET Framework 3.0
.NET Framework 3.0 SP1
.NET Framework 3.0 SP2
.NET Framework 3.5
.NET Framework 3.5 SP1
.NET Framework 4 Client
.NET Framework 4 Full

By default, the .NET Framework setup verification tool will only list versions of the .NET Framework that it detects are installed on the computer that it is being run on. As a result, the tool will not list all of the above versions of the .NET Framework. This product filtering can be overridden by running the .NET Framework setup verification tool with the following command line switch:

--> netfx_setupverifier.exe /q:a /c:"setupverifier.exe /a"

Silent installation mode

The .NET Framework setup verification tool supports running in silent mode. In this mode, the tool will run without showing any UI, and the user must pass in a version of the .NET Framework to verify as a command line parameter. To run in silent mode, you need to download the verification tool .zip file, extract the file netfx_setupverifier.exe from the .zip file, and then run it using syntax like the following:

--> netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p <name of product to verify>"

The value that you pass with the /p switch to replace <name of product to verify> in this example must exactly match one of the products listed in the Supported products section above. For example, if you would like to run the tool in silent mode and verify the install state of the .NET Framework 2.0, you would use a command line like the following:

--> netfx_setupverifier.exe /q:a /c:"setupverifier.exe /p .NET Framework 2.0"

Exit codes

The cleanup tool can returns the following exit codes:

0 - cleanup completed successfully for the specified product
1 - the required file setupverifier.ini was not found in the same path as setupverifier.exe
2 - a product name was passed in that cannot be verified because it does not support installing on the OS that the tool is running on
3 - a product name was passed in that does not exist in setupverifier.ini
100 - verification failed for the specified product
1602 - verification was canceled

Log files

This verification tool creates 2 log files by default that can be used to determine what actions the tool is taking and what errors it encounters while verifying a product. The 2 log files are listed below, and they are created in the %temp% directory by default. Note that you can find the %temp% directory by clicking on the Windows start menu, choosing Run, typing %temp% and clicking OK to open the directory in Windows Explorer.

%temp%\setupverifier_main_*.txt - this log contains information about all actions taken during a verification tool session; it will include information about each resource that the tool attempts to verify for a chosen product and whether or not that resource was found on the system; this log tends to be fairly long, so errors will be logged with the prefix ****ERROR**** to make it easy to search and find them
%temp%\setupverifier_errors_*.txt - this log only contains information about any errors found during verification of a chosen product
%temp%\setupverifier_netfx20testapp_*.txt - this log contains error information for the .NET Framework test application that is run by the verification tool. This log will only be created if there is an error while running the test application.

A new pair of log files will be created each time the verification tool is launched. The date and time the tool is launched will be appended to the end of the log file names by default in place of the * in the names listed above. If you want to control the exact names used for the log files, you can use the following command line parameters:

/l <filename> - specifies a name to replace the default value of setupverifier_main_*.txt for the main activity log for the verification tool
/e <filename> - specifies a name to replace the default value of setupverifier_errors_*.txt for the error log for the verification tool

For example, the following command line will allow you to specify non-default names for both log files:

--> netfx_setupverifier.exe /q:a /c:"setupverifier.exe /l %temp%\my_main_log.txt /e %temp%\my_error_log.txt"

=============================================================================================

Cheers,

Jorge

ADMT v3.2 Has Been Released

Jorge — Sun, 20 Jun 2010 14:26:36 GMT

"The Active Directory Migration Tool version 3.2 (ADMT v3.2) simplifies the process of migrating objects and restructuring tasks in an Active Directory® Domain Service (AD DS) environment. You can use ADMT v3.2 to migrate users, groups, service accounts, and computers between AD DS domains in different forests (inter-forest migration) or between AD DS domains in the same forest (intra-forest migration). ADMT can also perform security translation (to migrate local user profiles) when performing inter-forest migrations."

Download it from here.

Additional info about ADMT can be found here and here.

Latest ADMT Migration Guide can be downloaded from here.

Cheers,

Jorge

Managing The DSRM Administrator Account

Jorge — Tue, 15 Jun 2010 05:41:22 GMT

In a previous post I explained which type of accounts can be used to log on to a DC. For W2K8(R2) RWDCs/RODCs you can use the DSRM Administrator Account and domain accounts. When you can use which account depends on certain configuration as also specified in that same post.

With regards to the DSRM Admin Account, each DC has one, which also has a password that needs to be managed somehow. Let's have a look at the different possibilities. The DSRM Admin Account Password is set/configured during the promotion of the server to a DC. Afterwards you can RESET its password through NTDSUTIL. The exact command for that is shown below in the picture.

In this case, specifying NULL as the server, means the local DC. You can also specify the name of any other DC.

What's the downside of this approach? It is not scriptable, and that can be quite a pain when you have multiple DCs for which you want to manage the DSRM Admin Account password.

A former DS-MVP, which chose to join "the dark side" (I know you read this and you know who you are! J), wanted to script this and he solved this by using the SETPWD utility that was available in Windows 2000 Server SP2. But I think only the Windows 2000 SP3 vesion was scriptable. Check out MS-KBQ810037 and MS-KBQ239803. SETPWD is NOT available in Windows Server 2003 and later.

Unless you have a copy of that batch script, it cannot be downloaded anymore from its original location. But no worries! There is another way to achieve your goal! But seriously….Are you still running W2K? Hopefully not!

Since W2K8, there is another way to manage the password of the DSRM Admin Account. In W2K8(R2), the menu for "Set DSRM Password" in NTDSUTIL contains a new option as shown below in the picture.

Yes, the new option called "Sync from domain account %s" allows you to create and use a user in AD and sync the password from it!

Allow me to explain how you could implement this and what the rules are of using this new option. The following is just a way of how you could implement it and food for thought!

In this scenario I created a folder on drive C: called "SCRIPTS". In that folder a have a batch file (CMD) called "SYNC-DSRM-ACCOUNT-PASSWORD.CMD"

On RWDCs the content of that script is:

@ECHO OFF

CLS

COLOR 0E

ECHO ## START ## %COMPUTERNAME% ## %DATE% %TIME%>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

NTDSUTIL "SET DSRM PASSWORD" "SYNC FROM DOMAIN ACCOUNT ADCORP\DSRM-ADM-RWDC" Q Q>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

ECHO ## END ## %COMPUTERNAME% ## %DATE% %TIME%>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

ECHO.>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

On RODCs the content of that script is:

@ECHO OFF

CLS

COLOR 0E

ECHO ## START ## %COMPUTERNAME% ## %DATE% %TIME%>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

NTDSUTIL "SET DSRM PASSWORD" "SYNC FROM DOMAIN ACCOUNT ADCORP\DSRM-ADM-RODC" Q Q>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

ECHO ## END ## %COMPUTERNAME% ## %DATE% %TIME%>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

ECHO.>>C:\SCRIPTS\NTDSUTIL-SYNC-DSRM-PWD-FROM-DOMAIN-ACCOUNT-%COMPUTERNAME%.LOG

You might wonder WHY I'm using different scripts. Note the underlined lines above and check the differences. RODCs are implemented as one of the coolest features in W2K8 AD. By now you should understand the following two statements:

Each and every writable DC (RWDC) in the AD forest is and should be treated and considered as the most trusted and most secure machine. If an RWDC is compromised, the rest of your AD is toast if you do not react appropriately in time!
Each and every read-only DC (RODC) in the AD forest is and should be considered as an untrusted machine. When an RODC is compromised the impact on the AD forest is much much lower than when an RWDC is compromised.

Based upon the statements mentioned above, you DO NOT want to use the same AD user account to sync the password from for both RWDCs and RODCs. That's why you need at least two AD user accounts. One for RWDCs and one for RODCs. You do not want an RODC Admin to gain access to your RWDCs easily like that and/or you also do not want some hacker to pull out the password from a compromised RODC and use it on the RWDCs, That would be really to easy!

For RWDCs you could use the same AD user account as all RWDCs should be treated equally.

For RODCs you could use the same AD user account as all RODCs should be treated equally. You may need more AD user accounts if for example each AD site contains one or more RODCs which is/are managed by a different admin than in other AD sites. In that case you could create an AD user account for each AD site containing one or more RODCs.

That script can then either be triggered remotely on-demand through for example PSEXEC OR you could create a scheduled task on every DC (RWDCs and RODCs) that executes on a regular basis and then syncs the password to the local DSRM Admin Account.

On each RWDC I created a scheduled task with the following command:

SCHTASKS /CREATE /TN "SYNC DSRM ACCOUNT PASSWORD" /RU "NT AUTHORITY\SYSTEM" /SC WEEKLY /D MON /ST 23:59 /TR "CMD /C C:\SCRIPTS\SYNC-DSRM-ACCOUNT-PASSWORD.CMD"

On each RODC I created a scheduled task with the following command:

SCHTASKS /CREATE /TN "SYNC DSRM ACCOUNT PASSWORD" /RU "NT AUTHORITY\SYSTEM" /SC WEEKLY /D MON /ST 23:59 /TR "CMD /C C:\SCRIPTS\SYNC-DSRM-ACCOUNT-PASSWORD.CMD"

If I still need to sync the password on-demand I can still use PSEXEC to remotely use SCHTASKS on every DC. Note that the scheduled task has the same name on every DC.

As you can see above, the scripts log the results in a very simple way to a local file.

An example of the log file on RWDCs looks like:

An example of the log file on RODCs looks like:

An example of the AD user accounts used for this:

And now the rules of engagement with regards to the AD user account(s) used to sync the password from:

The AD user account must be in the same AD domain as the DC that will sync the password from it
Treat the AD user account from which you sync the password from as an high-privileged admin account!
The password of the AD user account must be stored in the local AD instance of each DC as NTDSUTIL will only look at the local AD instance. For RWDCs this is automatically achieved. For RODCs this is different and it means the following:
- The AD user account used by an RODC to sync the password from must be in the "Allowed To Cache" list. This is needed to allow the storage of the password on the RODC.
- The AD user account used by an RODC to sync the password from must have its password pre-populated on the RODC. The password of an AD user or computer account only replicates to an RODC, when the RODC requests it after forwarding authentication to the RWDC. It does not replicate automatically like other attributes. So, to prevent issues, you should pre-populate the password to the RODC on a regular basis, and especially when it is changed/reset. This can be done manually through ADUC/REPADMIN or automatically through a scheduled script that leverages REPADMIN. [1]
Both RWDCs or RODCs do not need special permissions to sync the password from the AD user account when configured the scheduled tasks to use the System Account
Synchronization of the password only works when the DC is operating in normal mode. It will not work when AD is stopped or when booted in DSRM
When the password is changed or reset, make sure end-to-end AD replication is finished before synching the password from it to the DCs
The AD user accounts used to sync the password from do not need any special permissions. The less, the better!
The AD user account properties can be:
- Change its primary group from "Domain Users" to "Domain Guests" (not really mandatory)
- Disabled the user account (not mandatory, but recommended)
- Configure it with "User cannot change password" (not mandatory, but recommended)
- Configure it with "Password Never Expires" (mandatory, because the sync cannot occur from an AD user account that has an expired password!)
The AD user account properties cannot be:
- Smartcard required
- Account has expired
It is recommended to change/reset the password on a regular basis of the AD user account(s) from which the password is synched from to the DSRM Admin Account on a given DC

[1] If needed, to delegate the PWD pre-population of the password belonging to a certain AD user/computer account, you need at least the "Read Only Replication Secret Synchronization" extended right (or control access right - CAR). In addition to that you need read/write permissions on the "msDS-Site-Affinity" of each AD user/computer account in the AD domain for which you want to pre-populate the password. When delegated permissions have been configured and using ADUC you might get an error like "An attempt to update the group membership information in the universal group cache failed". This can be ignored safely.

Cheers,

Jorge