Share via

(WAL) - Workflow Example - Create Home Directory

  • 01/23/2016

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
                  $account=$Domain+"\"+$SamName
                  $rights=[System.Security.AccessControl.FileSystemRights]::FullControl
                  $inheritance=[System.Security.AccessControl.InheritanceFlags]"ContainerInherit,ObjectInherit"
                  $propagation=[System.Security.AccessControl.PropagationFlags]::None
                  $allowdeny=[System.Security.AccessControl.AccessControlType]::Allow
                  $dirACE=New-Object System.Security.AccessControl.FileSystemAccessRule ($account,$rights,$inheritance,$propagation,$allowdeny)
                  $dirACL=Get-Acl $homedir
                  $dirACL.AddAccessRule($dirACE)
                  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

  • Anonymous
    September 27, 2016
    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.
  • Anonymous
    September 27, 2016
    @ 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.
    • Anonymous
      August 01, 2017
      Yes, I wasn't trying to imply you needed to supply all the answers in this example. My comment was more intended as additional information for anyone else who finds this example and who has a geographically-distributed infrastructure. In this instance, a New-Item on the remote path solves the issue of waiting for accounts to replicate, running Remote-Commands, and simplifies error handling a little bit.I personally find it useful when people point out gotchas they encountered with a useful process and offer a workaround, so I'm sharing the love. (I think it's the best use of comments on a technical article :-) )
  • Anonymous
    January 17, 2017
    Hi I have an Problem with the skrip.when I want to use the skipt I get an Error in the event viewer.I done the same like you in the tutorial.My Error is c : b__68_0: The term 'Set-ADUser' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.I hope you can help me.
    • Anonymous
      January 17, 2017
      1st what version of Windows Server are you running 2008, 2012, etcremember that you must pass an Invoke command when running this script against a server 2012 or higherfor example (Invoke-Command -ComputerName $Server -Script {param($SamName, $HomeDir, $DriveLet) Set-ADUser -Identity $SamName -Replace @{homeDirectory=$homedir;homeDrive=$DriveLet} -Confirm:$false} -Args $SamName, $HomeDir, $DriveLet)2nd have you verified that all characters copied over correctly? often characters such as , ' " do not copy over well and cause errors..