(WAL) – Workflow Example – Create Home Directory

The following Example is an illustration of how the PowerShell Workflow Activity could be used, some may argue that the PowerShell MA would be better suited for this type of activity and in a scenario where Bulk creations would be necessary i would agree, but this blog posting is to demonstrate that how to use the PowerShell Workflow Activity which is part of the Workflow Activity Library.

The below example is a modified version of the previously documented Post which was Documented using a Server 2008 Target Domain Controller . The below example can be used with Server 2012 R2 or earlier.

Additionally its important to note that this workflow should be triggered after the Synchronization Service updates the users resourceSid (objectSid) in the FIM Portal, this would be a good indication that the user object has been created in AD.


  • Click on New
    • Enter the name for your Workflow (I start all my workflows with an “_” which makes it easy to identify all non custom workflows.
    • Select Actions

  • Click on Next
  • Select WAL: Run PowerShell Script

    • Click on Select
  • Configure the 1st Workflow Activity
    • Type in the name for the Activity that will be used as part of the Workflow
      • Activity Display Name
        • Create Home Directory
      • Advanced Features
        • false (Leave unchecked)
      • Script Location
        • Include in Workflow Definition
      • Script
        • Param($SamName,$HomePath,$DriveLet,$Domian)
          ## Create Remote Session (verify that the FIM Service account has permission to run Remote Powershell on the target DC)
          $Server = “DC1”
          $dc1 = New-PSSession -ComputerName $Server
              # Any errors during execution of the script or the script block are bubbled up automatically.
              # Comment out -ComputerName parameter when running interactively

                      ## Uncomment for Manual Testing

             #     $SamName = “orangejuice”
             #     $homepath = “\\Svr2\e”
             #     $DriveLet= “H”
             #     $Domain = “Contoso”

          ##Set Variables
          $Spacer= ” “
          $HomeDir = $homepath + “\” + $SamName


                  #Create Home Directory
                  mkdir $homedir
                  #Assign Access Rights
                  $dirACE=New-Object System.Security.AccessControl.FileSystemAccessRule ($account,$rights,$inheritance,$propagation,$allowdeny)
                  $dirACL=Get-Acl $homedir
                  Set-Acl $homedir $dirACL

                  #Assign AD Attributes
                  #Enter-PSSession $dc1
                  Invoke-Command -ComputerName $Server -Script {param($SamName, $HomeDir, $DriveLet) Set-ADUser -Identity $SamName -Replace @{homeDirectory=$homedir;homeDrive=$DriveLet} -Confirm:$false} -Args $SamName, $HomeDir, $DriveLet

      • Input Type
        • Named Parameters
      • Named Parameters
        • Parameter 1
          • Parameter
            • SamName
          • Value Expression
            • [//Target/AccountName]
        • Parameter 2
          • Parameter
            • HomePath
          • Value Expression
            • “\\Svr2\e”
        • Parameter 3
          • Parameter
            • DriveLet
          • Value Expression
            • “H”
        • Parameter 4
          • Parameter
            • Domain
          • Value Expression
            • “Contoso”
      • Script Return Type
        • None
  • Click on Save

  • Click on Finish
Comments (2)

  1. @ TM Note that these blog postings are examples, and DO NOT COVER all possible scenarios. I have tried to write the blogs in such a way to give a guidance, not to be used as the final Script/ workflow etc. that will be used in someones environment. I would hope that who ever is installing / configuring Identity Management solution has taken these different scenarios in account and wrote the Workflow / Scripts that will be needed to best fit their environment.
    Thank you for you feedback.
    Additionally i could have added Look ups and verification within the script that would verify Accounts, Paths etc but what fun is that for the person deploying these workflows.
    Over used analogy i know but, I’m trying to teach how to fish not do all the fishing myself.

  2. TM says:

    Note that even if the synchronisation service has synched back the object’s SID, it doesn’t mean the account has propagated to all the DCs in the domain if it is a geographically-distributed environment. If you have file servers also at distributed locations, they won’t necessarily be able to resolve the account.

    Rather than using an Invoke-Command on the remote file server, we simply use New-Item \\UNC\path -ItemType Directory. You can apply ACLs in exactly the same way on a UNC path as well. Since you’re running New-Item and Get/Set-ACL in the current session, error-handling is straightforward. There seems to be no adverse effect on performance.

    If the DC closest to the file server hasn’t caught up yet, the directory is created successfully with the perms applied to an unresolved SID. Once replication has completed to the site, the SID resolves nicely to the account name.

    We used a similar method with Invoke-Command previously, but waiting for the maximum replication cycle to the more remote locations was not great for workflow handling.