Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
Home Directory Custom PowerShell Workflow

Discussion Home Directory Custom PowerShell Workflow

  • Wednesday, November 02, 2011 6:45 PM
     
     
    Sign In to Vote
    3

    I have attached a screenshot of the Custom PowerShell workflow used to create, attach, and apply permisions for a user and thier home directory  when createing a new user in FIM.

     

    Param($SamName,$SiteCode)

    Import-Module ActiveDirectory

    # Change these to work with FIM
    #$SamName = $args[0]
    #$SiteCode = $args[1]

    $Spacer="  "
    $SamName,$Spacer,$SiteCode | out-file -filepath c:\PSscripts\HomeDir.Log
    #Set Home Directory Path

    switch ($SiteCode)
    {
    SITE1 {$homedir = "\\HOMEDIRECTORYPATH\"+$SamName}
    SITE2 {$homedir = "\\HOMEDIRECTORYPATH\"+$SamName}
    SITE3 {$homedir = "\\HOMEDIRECTORYPATH\"+$SamName}
    default {""}
    }

    if ($homedir){
    #Create Home Directory
    mkdir $homedir

    #Assign Access Rights
     
          $account="YOURDOMAINHERE\"+$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
    Set-ADUser -Identity $SamName -Replace @{homeDirectory=$homedir;homeDrive="H:"} -Confirm:$false -CannotChangePassword:$true
    }
    Return "Success"

     

     

     

    Anthony Marsiglia
     

All Replies

  • Wednesday, February 08, 2012 11:00 PM
     
     
    Sign In to Vote
    0
     

    This is outstanding!  Any chance you could share the contents of your custom function “OUOffice”?   

    Montana DPHHS

     
  • Thursday, February 09, 2012 8:35 AM
     
     
    Sign In to Vote
    0

    FIM is frustrating to me because its not so clear when things happen.

    This sort of initial create script isnt so hard to produce as long as it is fired off after the AD account is created and replicated around the domain.

    How are renames (changing the samaccountname attribute) handled?

    Does FIM have any deferred action type Workflows so I can queue an xcopy and delete his current HomeDir script to fire off when he is not logged on?

     
  • Monday, June 25, 2012 10:57 PM
     
     
    Sign In to Vote
    0

    having a hard time understanding the question

    Depending on what your trying to accomplish but yes using a custom workflow activity that triggers powershell.

    Anthony Marsiglia

     
  • Monday, June 25, 2012 10:59 PM
     
     
    Sign In to Vote
    0
    OUOffice was a custom attribute in the portal, this script could have just as easily used any other attribute.

    Anthony Marsiglia

     
  • Wednesday, October 10, 2012 12:31 PM
     
     
    Sign In to Vote
    0

    When you run Set-ADUser whose credentials are you using?

    I see it as a custom activity inside a workflow that is run by a request of some sort, I cant follow which ad account is actually going to update the AD.

     
  • Wednesday, October 10, 2012 4:21 PM
     
     
    Sign In to Vote
    0
    This is run under the FIM Service account

    Anthony Marsiglia

     
  • Friday, October 12, 2012 6:34 AM
     
     
    Sign In to Vote
    0

    So FIMService account will need to be given write rights on various AD attributes via delegation or perhaps added to Account Operators group, then.

    From what I read of the FIM install, the FIMService domain account was used simply to start the FIMService service on the FIM server.

     
  • Friday, October 26, 2012 7:00 PM
     
     
    Sign In to Vote
    0
    This is run under the FIM Service account

    Anthony Marsiglia


    In my TONYB domain, I don't have a FIM service account.  Can you suggest any good names for me?
     
  • Friday, October 26, 2012 7:06 PM
     
     
    Sign In to Vote
    0
    Wouldn't this script fail if applied on new user creation, due to the fact that the account won't exist in AD until being Provisioned from the Sync Engine?
     
  • Friday, October 26, 2012 10:00 PM
     
     
    Sign In to Vote
    0

    this is just a workflow and yes if you ran this workflow or any PowerShell script against a user that didn't exist the PS Script would fail. the real question is how to trigger this workflow for a new user.

    after the user has been created in AD and is synced back in to the portal it could pick up a number of attributes depending on your environment, or you could use objectsid as a trigger.

    The MPR has the requester as Synchronization Account

    target is a set that would contain new users and the workflow is triggered by a modify of the Object Sid and considering the account does not have an object sid when created in FIM it would be a good attribute to use.

    does that answer your real question

    Anthony Marsiglia

     
  • Friday, October 26, 2012 10:01 PM
     
     
    Sign In to Vote
    1

    Dan my friend im honored that the TONYB domain lives on.

    Anthony Marsiglia

     
  • Friday, November 09, 2012 9:03 AM
     
     
    Sign In to Vote
    0

    Yes we all know that the PS script that can create home directories can only be triggered when FIM knows the AD account exists for sure.

    Strictly speaking it should also only be fired off when the new AD account details has been replicated around the domain, might be awkward to try and set permissions on the fileserver when it doesnt know about the account owning the new folder.

    I guess the only way we know that a new AD account has been created is when AD flows the objectSID attribute to MV which is in turn exported to FIM. Hopefully this delay allows the replication to happen.

    Question is.. how does an MPR trap the change in objectSID attribute. Our out-of-the-box implementation does not seem to show objectSID as one of the selectable single values attributes.

    Are we forced into extending the schema and creating our own attribute say ADexists on both FIM and MetaVerse. Then flow objectSID or the AD GUID from AD into this home brewed attribute??

     
  • Friday, November 09, 2012 2:15 PM
     
     
    Sign In to Vote
    0

    I currently have this method of Configuring Homedirectories in production for a customer for over a year now with no issue.

    The powershell script looks at the DC closest to the server that the PS Script is being triggered on. Since this server is in the same site as the DC that is in scope there has never been an issue. This particular customer has 54 DCs in their environment and yes replication can be an issue so having AD Change notification enabled on all DCs also helps but in this case its not really needed considering the PS Script looks at the DC closest.

    You could add in the PS Script which DC you want to fire the command on to further reduce any possible mis configurations.

    Look below and you can see that ObjectId and ObjectSid are in the portal as ResourceID and ResourceSID

    Does this seem to help If id does please give me positive feedback

    Attributes in the portal

    Anthony Marsiglia

     
  • Monday, November 12, 2012 7:08 AM
     
     
    Sign In to Vote
    0

    good news that Resource SID is ObjectSID from AD. Thanks for pointing that out.

    I still feel that there will have to be a delay until the Fileserver (which is highly unlikely to be a Domain Controller) gets told about the new AD account.

     
  • Wednesday, November 14, 2012 12:15 AM
     
     
    Sign In to Vote
    0
    I'm not sure if that was supposed to be sarcasm but like I have stated before this solution works and has worked flawlessly since FIM 2010 was setup for my customer. The File server is not now nor has it ever been a DC and nor would I recommend such a configuration. Keep in mind that this may not be the best solution but it works and if anyone comes up with a better solution I am all ears in fact I welcome improvements on any of the work I have done. I would also recommend consulting with an AD Specialist that may be better to explain how this works and other possible solutions.

    Anthony Marsiglia

     
  • Tuesday, November 20, 2012 12:03 AM
     
     
    Sign In to Vote
    0
    This solution works great in my environment. We soon will be able to get all of our admins out of ADUC. Thanks for the post!!!