• State Verified Answer
  • Locked Locked
  • Replies 13 replies
  • Subscribers 61 subscribers
  • Views 15407 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Create or Move Exchange Mailbox with Workflow

F.Ballango
over 8 years ago

Hello,


we are using ActiveRoles Version 7.

We want to automate User creation with workflows, but i have problems with the Mailbox creation.

We want to minimize the Rules we are using, so my Test approach is on Policy and after this the Settings are applied to the new user depending of the OU where the user is created.

With Mailbox creation i have tested the following:
1. Workflow sets the attributes mailnickname and homeMDB; in a later Step edsaCreateMsEchangeMailbox --> not working with Error Message "external Mail Address is missing"

2. created a default Policy with automatic creation of the Mailbox in the selected Store, the Workflow sets edsahomeMDB and edsaMoveMailbox "True" --> Error edsahomeMDB is missing

3. created a default Policy with automatic creation of the Mailbox in the selected Store, the Workflow sets extensionAttribute8 with the DN of the correctStore; a second Workflow starts a script which reads the User DN, extensionAttribute8 and mailNickname and starts "Set-QADUser $user -Proxy -ObjectAttributes @{"edsaMoveMailbox"=$true;"edsaHomeMDB"=$strEDSAhomeMDB}" --> Error Access Denied"

When i start a powershell with the User of our ActiveRoles Server Service the command "Set-QADUser $user -Proxy -ObjectAttributes @{"edsaMoveMailbox"=$true;"edsaHomeMDB"=$strEDSAhomeMDB}" works fine.

Does someone has a solution or concept for this ?

Is there some way to delete a moverequest from exchange when it is finished ?


Regards,

Florian Ballangó

  • 0 over 8 years ago

    Why would you not just configure a ARS policy to control where the mailbox is created? 

    Personally I don't like to hard code anything in scripts because they are loaded guns.  A simple change in the Exchange configuration here will break the script.  In this case that's probably true even if you use ARS policies, you have to remember the dependencies when you make infrastructure changes.  How good if you CMDB?

    Two things I generally do in my script policies are send regular email reports on the scripts including the parameters so hopefully I'll see that a script needs to be updated if there is an infrastructure change and I always use parameters ( using onInit function - does that work for workflows? ) that can be managed in the script / policy object configuration for any "hard coded" values that I'd like to use in a script as at least you can then just update these rather than edit your script when you make a change.

  • 0 over 8 years ago

    Hello Lee,

    the problem is that Exchange Mailbox creation with Policys has some restrictions. We want to assign a Database based on the Organizational Unit where the User is created.
    I have fount two ways to do this:

    1. Create a Policy for Mailbox Creation on the affected OU`s
    2. Create a Workflow or Script to do this

    The first Solution is implemented and we want to minimize the amount of Policys. This is why we want to use the Second solution.

    When we change our Infrastructure, i need to change the Policys or the Script. I am a beginner with this an can not tell you if there is a better way with activeroles.

    I don´t know if it is better for us to use Parameters, because i see no difference if i edit the Parameters or the Script.

    Best Regards,

    Florian

  • 0 over 8 years ago

    Glad to hear you made some progress!

    To answer your question about the Parameters - the idea with those is that you can pass information to your script through the parameters.  For example, a script calling a workflow and providing it some values for the parameters.

    In your case, I don't think there's any particular benefit.

    One thing I might suggest though is that for the DB selection, you create an OU->DB "mapping table" that you store in a file and load from the script.  Unless you have a very large number of databases, this will be a relatively efficient way to store your DB list outside of the script so that if you need to update it, you can just change the list and not be concerned about breaking the script.

    The table would look like this:

    London=DB1
    NewYork=DB2
    Chicago=DB3

    Assume we save this as "Mytable.txt"

    Here's some sample code:

    $LookupData = Get-Content -raw "Mytable.txt" | ConvertFrom-StringData

    $DBToFind = "London"

    $TargetDB = $LookupData[$DBToFind]

    ...returns "DB1"