nerdexam

70-158 · Question #10

You use Forefront Identity Manager (FIM) 2010 in your company network. After you perform the migration of FIM from the test environment to the production environment, you discover that requests for…

The correct answer is D. Move custom DLLs from the test environment to the production environment. When migrating FIM 2010 from a test environment to production, custom workflow assemblies (DLLs) must be physically copied to the production server, as they are not transferred automatically during configuration migration.

Submitted by anjalisingh· Mar 4, 2026Configure policies and workflows

Question

You use Forefront Identity Manager (FIM) 2010 in your company network. After you perform the migration of FIM from the test environment to the production environment, you discover that requests for custom workflows fail. You need to ensure that custom workflows perform properly in the production environment. What should you do?

Options

  • AEnable firewall access for Port 5725.
  • BDelete custom DLLs in the production environment.
  • CImplement the IActivitySettingsPart interface in Microsoft Visual Studio.
  • DMove custom DLLs from the test environment to the production environment.
  • ERun the CommitChanges.ps1 PowerShell script in the production environment.

How the community answered

(37 responses)
  • A
    22% (8)
  • B
    3% (1)
  • C
    8% (3)
  • D
    62% (23)
  • E
    5% (2)

Why each option

When migrating FIM 2010 from a test environment to production, custom workflow assemblies (DLLs) must be physically copied to the production server, as they are not transferred automatically during configuration migration.

AEnable firewall access for Port 5725.

Port 5725 is the FIM Service port used for client-to-service communication, and enabling it would not resolve missing custom workflow assemblies that fail to load on the server side.

BDelete custom DLLs in the production environment.

Deleting custom DLLs would remove the workflow assemblies entirely, making the problem worse rather than resolving the failed custom workflow requests.

CImplement the IActivitySettingsPart interface in Microsoft Visual Studio.

Implementing IActivitySettingsPart is a development-time task used to create a configuration UI for custom workflow activities in Visual Studio, not a deployment step required to make existing workflows function in production.

DMove custom DLLs from the test environment to the production environment.Correct

Custom workflows in FIM 2010 are implemented as managed code assemblies (DLLs) that must reside in the correct directory on the FIM Service server. When migrating between environments, these custom DLLs are not included in standard FIM configuration exports and must be manually copied from the test environment to the production environment. Without the DLL files present on the production server, the FIM Service cannot load or execute the custom workflow activities, causing requests to fail.

ERun the CommitChanges.ps1 PowerShell script in the production environment.

CommitChanges.ps1 is used to apply FIM configuration changes or schema updates, but it does not deploy or register custom workflow assemblies needed for custom workflows to execute.

Concept tested: Deploying custom workflow assemblies in FIM 2010

Source: https://learn.microsoft.com/en-us/previous-versions/mim/ff602273(v=ws.10)

Topics

#Custom Workflows#FIM Migration#Custom DLLs

Community Discussion

No community discussion yet for this question.

Sign up to join the discussion
Full 70-158 Practice