Hello,
Issues with Welcome Email
The value of %sAMAccountName% is not resolved correctly because of how value references work in Adaxes. The thing is that when an operation triggers any Business Rules with value references, those are resolved at once and not re-resolved in the course of Business Rule execution. Thus, in your case, the %sAMAccountName% reference is resolved at the very beginning of the Create User action, before a proper username is set by the script / Property Pattern.
The value of %unicodePwd% is not resolved for the same reason. The value reference is resolved at the very beginning of the action, before the Reset password for the User action sets a password.
To resolve both the issues, we suggest creating a Business Rule triggered after resetting a password for the user. Since resetting a password is a completely different operation than creating a user, the value references will be resolved again and correctly.
Also, in your Business Rule triggered after creating a user, we suggest adding a flag indicating that a new user has been created, and that the user needs a welcome email. Thus, in the Business Rule triggered after resetting a password, you can use the flag to understand whether you need to send the welcome email or not.
As a flag, we suggest using one of Adaxes custom attributes, e,g, CustomAttributeBoolean1. Such attributes are not stored in AD, but can be used the same as any other attributes of AD objects.
To do so:
i. Change the Business Rule triggered after creating a user
First, you need to change the Business Rule triggered after creating a user. You need to add a flag indicating that the user needs a welcome email and remove the action that sends an email message. To do so:
- In the Console Tree of the Administration Console, navigate to and select the Business Rule triggered after creating a user.
- Right-click the Reset password action and select Add New Action.
- Select Update the User and click Add.
- In the Property to modify list, select the property you want to use as a flag (e.g. CustomAttributeBoolean1).
- In the New value field, specify True.
- Click OK 2 times.
- Use the arrow buttons at the bottom to make the action the 1st in the Business Rule.
- Remove the whole set with the Send e-mail notification action.
- Save the changes. You should receive something like this:
ii. Create a Business Rule triggered after resetting a password
To create a Business Rule that sends welcome emails:
- Create a new Business Rule.
- On step 2 of the Create Business Rule Wizard, select User and After Resetting a password for a User.
- On step 3, add the Send e-mail notification action.
- Specify the action parameters.
- Click OK.
- Now, we need to add an action that removes the flag in order to avoid sending a welcome message to the user again. To do this, right-click the action you've just added and select Add New Action.
- Select Update the User and click Add.
- In the Property to modify list, select the property you want to use as the flag for new user (e.g. CustomAttributeBoolean1).
- Select Remove the property.
- Click OK 2 times.
- Now, you need to add a condition to send the email only when the flag is set. To do this, right-click the action again and select Add Condition.
- Select If <property> <relation> <value>.
- Specify If CustomAttributeBoolean1 equals True, where CustomAttributeBoolean1 is the property you want to use as the flag for new user.
- Click OK. You should receive something like the following:
Changes to the Repository Script
In order for the script to update not only Employee ID, but also User Logon Name and User Logon Name (pre-Windows 2000), add the following lines to the very end of the script:
# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("sAMAccountName", $uniqueValue)
# Update User Logon Name
$domain = $Context.GetObjectDomain("%distinguishedName%")
$Context.SetModifiedPropertyValue("userPrincipalName", "$uniqueValue@$domain")