none
Build FIM Development Environment RRS feed

  • Question

  • Good Afternoon,

    My institution is looking to implement FIM, however, we currently have no test/development FIM environment.  Our current production environment consists of 1 Forest and less than 10 Domains

    Is there any guidance outlining how to establish a development environment for FIM without compromising the integrity of your production Forest/Domains?  Possibly build a DEV Forest in a segregated vlan so that it can't talk to production - then install all the FIM prereqs in the DEV Forest?

    Thank you,
    T

    Thursday, December 13, 2012 6:11 PM

Answers

  • In order to have a real dev environment, you will need to build a new AD forest that has no trust relationship with production.  This is part of the challenge of doing meaningful, non-destructive testing with FIM / AD generally--there are *so many* dependencies that are not feasible to deploy and test in a separate environment.

    Short of that, you could set up FIM in a production AD environment but use service accounts that have read-only access, or delegated access to only a few very restricted OUs; however, this provides no or limited opportunity to test provisioning, deprovisioning, password sync, and so on.


    Steve Kradel, Zetetic LLC SMS OTP for FIM | Salesforce MA for FIM

    • Marked as answer by Misterr T Monday, December 17, 2012 2:24 PM
    Thursday, December 13, 2012 7:51 PM
  • I haven't seen particular guidance for a dev/test environment because every environment is unique and each location is going to have its own requirements.  We use a physically isolated test environment with its own copy of the ERP system, AD, Exchange, Lync, etc.  Some things like file shares on multiple servers I fake with shares on one server and a bunch of aliases.  Because it is physically isolated, it can use the same internal DNS namespace without any conflicts.  Our external DNS is split out from the internal, and the test environment has its own public namespace that allows firewall testing and the like.  The Windows-based systems started out on surplussed, end-of-life hardware, but increasingly are being done with virtual servers since the EOL hardware is rarely x64-capable.  MSDN licenses for the various pieces keeps the R&D environment from costing what the production environment does on the software side.

    I use my disaster recovery FIM server to stage code/config changes before rolling them to production in the main site.  That server's scripts do not execute any run profiles with export steps in them, at least not for MAs that reach out to normal production systems.  That way I can validate how the code changes behave with data from the real environment (AD, etc.) that hasn't experienced the "drift" seen in the R&D environment.  Refreshing R&D is non-trivial, since all groups (ERP, AD, network infrastructure, etc.) can and do use it for testing and almost everything is interdependent to one degree or another.

    Chris

    • Marked as answer by Misterr T Monday, December 17, 2012 2:24 PM
    Thursday, December 13, 2012 10:35 PM

All replies

  • In order to have a real dev environment, you will need to build a new AD forest that has no trust relationship with production.  This is part of the challenge of doing meaningful, non-destructive testing with FIM / AD generally--there are *so many* dependencies that are not feasible to deploy and test in a separate environment.

    Short of that, you could set up FIM in a production AD environment but use service accounts that have read-only access, or delegated access to only a few very restricted OUs; however, this provides no or limited opportunity to test provisioning, deprovisioning, password sync, and so on.


    Steve Kradel, Zetetic LLC SMS OTP for FIM | Salesforce MA for FIM

    • Marked as answer by Misterr T Monday, December 17, 2012 2:24 PM
    Thursday, December 13, 2012 7:51 PM
  • I haven't seen particular guidance for a dev/test environment because every environment is unique and each location is going to have its own requirements.  We use a physically isolated test environment with its own copy of the ERP system, AD, Exchange, Lync, etc.  Some things like file shares on multiple servers I fake with shares on one server and a bunch of aliases.  Because it is physically isolated, it can use the same internal DNS namespace without any conflicts.  Our external DNS is split out from the internal, and the test environment has its own public namespace that allows firewall testing and the like.  The Windows-based systems started out on surplussed, end-of-life hardware, but increasingly are being done with virtual servers since the EOL hardware is rarely x64-capable.  MSDN licenses for the various pieces keeps the R&D environment from costing what the production environment does on the software side.

    I use my disaster recovery FIM server to stage code/config changes before rolling them to production in the main site.  That server's scripts do not execute any run profiles with export steps in them, at least not for MAs that reach out to normal production systems.  That way I can validate how the code changes behave with data from the real environment (AD, etc.) that hasn't experienced the "drift" seen in the R&D environment.  Refreshing R&D is non-trivial, since all groups (ERP, AD, network infrastructure, etc.) can and do use it for testing and almost everything is interdependent to one degree or another.

    Chris

    • Marked as answer by Misterr T Monday, December 17, 2012 2:24 PM
    Thursday, December 13, 2012 10:35 PM