error when creating user

Question

1 Answer

Related questions

0 votes

0 answers

I have been getting the following error when running the built in user creation script. This has worked fine up until about 2 months ago. As you can see Adaxes sees my ... error. The account that I am using has the correct permissions to Exchange as well.

asked Dec 9, 2020 by joshua.velez (20 points)

0 votes

1 answer

Error when creating an user

Hi all, I want to create an external Username (username-ext). Loginname is the same as the initials. Changing the intiakls -> intials-ext ... CommandPipeline.Actions.ActionBase.Execute(ICommand command) --- Ende der internen Ausnahmestapelüberwachung ---

asked Jun 13, 2016 by massimo.ibba (450 points)

0 votes

1 answer

Error when creating users

Hi When one of our admins create a user through the webinterface, the following error appears, and the user is not created: Access to the attribute is not permitted because ... is owned by the Security Accounts Manager (SAM). (Server: domain.local) Any ideas?

asked Jun 4, 2013 by kjesoo (960 points)

0 votes

1 answer

Error creating user

Hello, We have hybrid setup with Azure AD sync. Sometimes when creating a user, we face below warning where in user is just created on-prem and not on o365. This is the ... happens after couple of user creations. Please let me know if there is any fix. Thanks!

asked Feb 3, 2021 by sarang.raval (20 points)

0 votes

1 answer

When creating users, does Adaxes generate any type of unique number after user creation?

I’m looking for a way to take a unique number from Adaxes and use part of it to create an employee ID for the AD attribute field.

asked Dec 25, 2023 by cewilson (190 points)

Support · Answer 1 · 2013-10-18T19:58:02+0000

thanks. I did remove it.
I put it back and all is well.

Another Error when adding user to a group, I get the below: FYI - the user account is not apart of the HR manager-copy rule. and I am using the Member of field within the form, which I think is the reason why...but I'd like you to confirm.

Just to clarify, when I create a user, I want to be able to add them to a group manually.

"Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM). (Server: newscorp.com)

Details

Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM). (Server: newscorp.com)

Business Rules: Command Processor 'Business Rules' threw an exception when processing the command. A list of actions to be triggered by Business Rules couldn't be generated. Failed to check the following condition of the 'User Provision' business rule: If the initiator is assigned to the 'Builtin\HR Manager - copy' role. The 'distinguishedName' property cannot be found in the cache"

commented Oct 18, 2013 by MeliOnTheJob (1.7k points)

Hello,

Yes, sure. The thing is that when you add a user to a group, you don't modify the user, you modify the group. You add the user's Distinguished Name (DN) to the Member property of the group. The Member Of property of the user is updated automatically by Active Directory, and Active Directory does not allow anyone update the property.

Also, you cannot add the user to a group before a user is created. When a user is not yet created, he/she does not yet have a Distinguished Name. That is, there is yet nothing to store in the Member property of the group.

In the Web Interface forms that are used for viewing/editing users, the Member Of section (not property) is used to update the user's membership in group. That section was especially designed to allow adding/removing users from groups directly from the pages for viewing/editing users. That section updates the Member property of the group that you add the user to. But as we've already mentioned above, this approach cannot be used as the new user does not yet have a DN that can be added to the Member property of the group.

To workaround this, you can add newly created users to groups automatically with a Business Rule triggered after creating a user. For example, take a look at the following tutorial that describes how to accomplish the task: http://www.adaxes.com/tutorials_Automat ... rtment.htm .

Alternatively, we can suggest the following approach: you can add one more text field to the form for creating users. For this purpose you can use one of Adaxes virtual properties, for example, CustomAttributeText1. In that field you can specify the name(s) of the group(s) the newly created user should be added to. Then, you can create a Business Rule triggered after creating a user that will use a PowerShell script to read the group name(s) stored in the virtual property and add the user to the specified groups. The only drawback of the method is that you will have to type in the groups manually, there won't be a window to select/browse for groups. If you are interested in such a solution, we will provide more details.

commented Oct 21, 2013 by Support (216k points)

Hello,

To take such a situation into account, you can automatically send an email notification to the user who sent the operation for approval if the operation fails. To do this, you need to create a Business Rule as follows:

Create a new Business Rule.
On the 2nd step of the Create Business Rule wizard, select User and After Creating a User.
On the 3rd step, add the Send e-mail notification action.
In the Action parameters section, specify the %adm-InitiatorEmail% value reference in the To field. When the action will be triggered, the value reference will be replaced with the email address of the user who sent the operation for approval.
Modify the message template and click OK.
Double-click the If the operation succeeded condition.
In the Condition parameters section, select If the main operation failed.
Click OK and finish creation of the Business Rule.

Also, we would advise completely eliminating such situations when user creation could fail. For example, if user creation failed because the users have identical usernames specified, you can create a Business Rule that will automatically add a digit to the username if the username is not unique. For information on how to accomplish the task, take a look at the following tutorial: http://www.adaxes.com/tutorials_Simplif ... Script.htm (Example 2 in step 5).

commented Nov 6, 2013 by Support (216k points)

If I go w/ the second option, within the example, it doesn't update the email address.

The script can be modified to update all the properties you need. How is email address generated?

Would I create a B.R. that runs the powershell script and if its true, then it will update the logon name etc., then have it sent to the hiring manager for approval?
Having the powershell do its thing, will that also update the fields within the notification email?
Once its approved, will the updated info be in the Request Approved form that the initiator receives?

If you do it as described in the tutorial, then everything will be automatically updated in the Approval Request, notifications sent to the initiator and approver etc. You only need to keep in mind that the PowerShell script should be triggered before sending for approval. That is, the script that generates a unique username and the Send operation for approval action should be in the same Business Rule, and the script should precede the Send operation for approval action.

commented Nov 6, 2013 by Support (216k points)

Hello,

The following script also updates the user's e-mail address. Use it instead of the script that you currently have.

Import-Module Adaxes
$emailLocalPart = "%firstname,1%%lastname%" # TODO: modify me

function IsUserNameUnique($username)
{
   $user = Get-AdmUser $username -erroraction silentlycontinue
   return $user -eq $Null
}
# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Check if the username is unique
if (IsUserNameUnique($username))
{
    return
}
# If the username is not unique, generate a unique one
$uniqueUsername = $Null
for ($i = 1; $True; $i++)
{
    $uniqueUsername = $username + $i;
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$domainName = $Context.GetObjectDomain("%distinguishedName%")
$userLogonName = $uniqueUsername + "@" + $domainName
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
  + ".", "Information")

# Update email address
$mailAddress = "$emailLocalPart$i@$domainName"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

commented Nov 18, 2013 by Support (216k points)

Sorry, we forgot about the requirement to have a custom UPN suffix in your environment. Here's a script that meets your requirements. The custom UPN suffix is specified by $upnSuffix.

Import-Module Adaxes
$emailLocalPart = "%firstname,1%%lastname%" # TODO: modify me
$upnSuffix = "example.com" # TODO: Modify me

function IsUserNameUnique($username)
{
   $user = Get-AdmUser $username -erroraction silentlycontinue
   return $user -eq $Null
}
# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Check if the username is unique
if (IsUserNameUnique($username))
{
    return
}
# If the username is not unique, generate a unique one
$uniqueUsername = $Null
for ($i = 1; $True; $i++)
{
    $uniqueUsername = $username + $i;
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$userLogonName = $uniqueUsername + "@" + $upnSuffix
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
  + ".", "Information")

# Update email address
$mailAddress = "$emailLocalPart$i@$domainName"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

commented Nov 26, 2013 by Support (216k points)

Hello,

Instead of using a number to make the username unique.
we'd like to make the username firstName.lastName if its not unique. can I have an updated script for this?

And what should the script do if firstName.lastName is also not unique?

once they receive a message that the account already exist and need to modify the user logon name(pre Windows 2000) to make it unique. How can I make user logon name= user logon name(pre windows 2000) w/o affecting the integrity of the form itself?

May be we are not getting something, but since you have a script that always generates a unique username, users are not supposed to0 see such a message if the username is non-unique. With the script in place, they can see such a message only if a user with the same full name exists in the same OU.

commented Nov 27, 2013 by Support (216k points)

Hello,

And what should the script do if firstName.lastName is also not unique?

I guess at that point the number can be added. Listings in the GAL with numbers at the end of usernames/email addresses wouldn't be a first choice. Also in the past when numbers were added, it was b/c of either corrupted account for diff resources for an example, which eventually got really messy.

once they receive a message that the account already exist and need to modify the user logon name(pre Windows 2000) to make it unique. How can I make user logon name= user logon name(pre windows 2000) w/o affecting the integrity of the form itself?

May be we are not getting something, but since you have a script that always generates a unique username, users are not supposed to0 see such a message if the username is non-unique. With the script in place, they can see such a message only if a user with the same full name exists in the same OU.

The script will be used only when HR is creating accounts. Trying to make the process seamless as possible since its a bit challenging to have them use the new system.

I didn't apply this script with our helpdesk b/c there is no approval process in place since its just service/resource accounts.

commented Nov 27, 2013 by MeliOnTheJob (1.7k points)

Hello,

I guess at that point the number can be added. Listings in the GAL with numbers at the end of usernames/email addresses wouldn't be a first choice. Also in the past when numbers were added, it was b/c of either corrupted account for diff resources for an example, which eventually got really messy.

OK. Here's a version of the script that first attempts to switch to the firstName.lastName format for the username and e-mail. If such a user also exists, it will start adding a number to the end of the username in the format firstName.lastName.

Import-Module Adaxes
$upnSuffix = "example.com" # TODO: Modify me

function IsUserNameUnique($username)
{
   $user = Get-AdmUser $username -erroraction silentlycontinue
   return $user -eq $Null
}
# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Check if the username is unique
if (IsUserNameUnique($username))
{
    return
}
# If the username is not unique, generate a unique one
$username = "%firstname%%lastname%"
$uniqueUsername = $username
for ($i = 1; $True; $i++)
{
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }

    $uniqueUsername = $username + $i;
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$userLogonName = $uniqueUsername + "@" + $upnSuffix
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
  + ".", "Information")

# Update email address
$mailAddress = "$uniqueUsername@$upnSuffix"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

once they receive a message that the account already exist and need to modify the user logon name(pre Windows 2000) to make it unique. How can I make user logon name= user logon name(pre windows 2000) w/o affecting the integrity of the form itself?

I didn't apply this script with our helpdesk b/c there is no approval process in place since its just service/resource accounts.

OK. So, as far as we understand, for these service accounts the user logon name should be equal to the user logon name(pre windows 2000), and your custom UPN suffix should be ignored. Is that correct?

Where (and how) do your helpdesk people create the accounts? Maybe they are created in a special OU or there's a separate Home Page Action for service accounts?

commented Nov 28, 2013 by Support (216k points)

Hello,

To generate User Logon Name based on User Logon Name (pre-Windows 2000), do the following:

Launch Adaxes Administration Console.
Expand the service node that represents your service.
Expand Configuration \ Property Patterns.
Select the Property Pattern that sets the custom UPN suffix (the one that you sent us).
Double-click the User Logon Name property.
In the Generate default value field, type %samAccountName%@domain.com, where domain.com is your custom UPN suffix.
Click OK and save the Property Pattern.

%samAccountName% is a value reference that will be replaced with the value of the User Logon Name (pre-Windows 2000) property. Since you specified an identical template for generating both the properties (save the custom UPN suffix), this will not break anything.

Also, can you clarify if there is a difference with regards to group membership between ‘Write All Properties’ and ‘Write member property’ ?

The Write All Properties permission allows a user to modify all properties of an object. With regards to groups, this allows to modify not only group membership, but also all other properties, such as, for example, Group Name, Description or Managed By. The Write 'member' Property permission allows only to add/remove members from the group, and nothing else.

commented Dec 4, 2013 by Support (216k points)

Hello,

Here's a modified version of the script that meets your requirements. in the script, $consultantsOUDN specifies the Distinguished Name (DN) of the OU with accounts of consultants.

Import-Module Adaxes
$upnSuffix = "example.com" # TODO: Modify me
$consultantsOUDN = "OU=consultants,DC=domain,DC=com" # TODO: Modify me

function IsUserNameUnique($username)
{
   $user = Get-AdmUser $username -erroraction silentlycontinue
   return $user -eq $Null
}

# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Check if the username is unique
if (IsUserNameUnique($username))
{
    return
}

# If the username is not unique, generate a unique one
$userDN = $Context.TargetObject.ObjectInfo.DN
if ($userDN.IsDescendantOf($consultantsOUDN))
{
    $username = "consultant.%firstname,1%%lastname%"
}
else
{
    $username = "%firstname%%lastname%"
}

$uniqueUsername = $username
for ($i = 1; $True; $i++)
{
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }

    $uniqueUsername = $username + $i;
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$userLogonName = $uniqueUsername + "@" + $upnSuffix
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
  + ".", "Information")

# Update email address
$mailAddress = "$uniqueUsername@$upnSuffix"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

commented Dec 25, 2013 by Support (216k points)

Hello,

Here's the script that you can use with multiple OUs for consultants. Specify the OUs where consultants are located in $consultantsOUDNs.

Import-Module Adaxes
$upnSuffix = "example.com" # TODO: Modify me
$consultantsOUDNs = @("OU=Temp_consultants_Intern_Accounts,OU=NY,DC=domain,DC=com", "OU=Temp_consultants_Intern_Accounts,OU=LA,DC=domain,DC=com", "OU=Temp_consultants_Intern_Accounts,OU=DC,DC=domain,DC=com") # TODO modify me

function IsUserNameUnique($username)
{
    $user = Get-AdmUser $username -erroraction silentlycontinue
    return $user -eq $Null
}

function IsConsultant ($userDN, $consultantsOUDNs)
{
    foreach ($ouDN in $consultantsOUDNs)
    {
        if ($userDN.IsDescendantOf($ouDN))
        {
            return $True
        }
    }
    return $False
}

# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")
# Check if the username is unique
if (IsUserNameUnique($username))
{
    return
}

# If the username is not unique, generate a unique one
$userDN = $Context.TargetObject.ObjectInfo.DN
if (IsConsultant $userDN $consultantsOUDNs)
{
    $username = "consultant.%firstname,1%%lastname%"
}
else
{
    $username = "%firstname%%lastname%"
}

$uniqueUsername = $username
for ($i = 1; $True; $i++)
{
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }
    $uniqueUsername = $username + $i;
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$userLogonName = $uniqueUsername + "@" + $upnSuffix
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
    + ".", "Information")

# Update email address
$mailAddress = "$uniqueUsername@$upnSuffix"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

What would be the best way to check that its an consultant account if there are 3 OUs and the initiator is in the HR group?

If it is for the purpose of setting the correct username, then the check whether it is a consultant is already done in the script, and you do not need to make any additional modifications to your Business Rule besides applying the new version of the script provided above. If it should be done for other purposes, could you explain your task in more detail?

commented Dec 27, 2013 by Support (216k points)

2 things -

Will the script only check for unique username within the OUs or will it check across the entire domain?
I attempted to add temp and intern code (my 2nd request below) and it actually created 2 accounts with the same username. Was it because I changed the $consultantsOUDNs to point to an test OU or did I totally screw up the code :oops: ?
I'd like to knw where I went wrong and confirm that it will check across the domain.
can this script be updated to include temp and intern?
temp, intern, and consultants will be located in the same OUs, however the naming convention is different for each with it being temp.firstNameInitialLastNameInitial, and intern.firstNameInitialLastNameInitial...and if those are already taken, the user account should be temp.firstNameInitialLastName.....intern.firstNameInitialLastName etc.

Temporarily - I am telling HR to ensure the user logon name pre windows is set to what you'd like the email address to be, but I'd like a better solution.

Essentially, we like to be able to select an employee type and based on that, the user logon name pre win 2000, user logon name, and email to match while the user is filling out the form.
not sure if that's possible in real time(I changed the option to generate value on creating and editing obj but that didn't work for me or I'm misunderstanding it). or if its better created as a Business rule?

my attempt at adding to the script

Import-Module Adaxes  
$upnSuffix = "domain.com" # TODO: Modify me  
$consultantsOUDNs = @("OU=Operation Team,DC=domain,DC=com") # TODO modify me  

function IsUserNameUnique($username)  
{  
 $user = Get-AdmUser $username -erroraction silentlycontinue  
 return $user -eq $Null  
}  

function IsConsultant ($userDN, $consultantsOUDNs)  
{  
 foreach ($ouDN in $consultantsOUDNs)  
 {  
 if ($userDN.IsDescendantOf($ouDN))  
 {  
 return $True  
 }  
 }  
 return $False  
}  

function IsTemp ($userDN, $consultantsOUDNs)  
{  
 foreach ($ouDN in $consultantsOUDNs)  
 {  
 if ($userDN.IsDescendantOf($ouDN))  
 {  
 return $True  
 }  
 }  
 return $False  
}  

function IsIntern ($userDN, $consultantsOUDNs)  
{  
 foreach ($ouDN in $consultantsOUDNs)  
 {  
 if ($userDN.IsDescendantOf($ouDN))  
 {  
 return $True  
 }  
 }  
 return $False  
}  

# Get the username  
$username = $Context.GetModifiedPropertyValue("samAccountName")  

# Check if the username is unique  
if (IsUserNameUnique($username))  
{  
 return  
}  

# If the username is not unique, generate a unique one  
$userDN = $Context.TargetObject.ObjectInfo.DN  
if (IsConsultant $userDN $consultantsOUDNs)  
{  
 $username = "consultant.%firstname,1%%lastname%"  
}  
else  
{  
 $username = "consultant.%firstname%%lastname%"  
}  

if (IsTemp $userDN $consultantsOUDNs)  
{  
 $username = "temp.%firstname,1%%lastname%"  
}  
else  
{  
 $username = "temp.%firstname%%lastname%"  
}  

if (IsIntern $userDN $consultantsOUDNs)  
{  
 $username = "intern.%firstname,1%%lastname%"  
}  
else  
{  
 $username = "intern.%firstname%%lastname%"  
}  

$uniqueUsername = $username  
for ($i = 1; $True; $i++)  
{  
 if (IsUserNameUnique($uniqueUsername))  
 {  
 break  
 }  
 $uniqueUsername = $username + $i;  
}  

# Update User Logon Name (pre-Windows 2000)  
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)  

# Update User Logon Name  
$userLogonName = $uniqueUsername + "@" + $upnSuffix  
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)  
$Context.LogMessage("The username has been changed to " + $userLogonName `  
+ ".", "Information")  

# Update email address  
$mailAddress = "$uniqueUsername@$upnSuffix"  
$Context.SetModifiedPropertyValue("mail", $mailAddress)  
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

commented Jan 8, 2014 by MeliOnTheJob (1.7k points)

Hello,

1.Will the script only check for unique username within the OUs or will it check across the entire domain?

The script checks within the entire domain.

can this script be updated to include temp and intern?
temp, intern, and consultants will be located in the same OUs

Yes, this can be done, however the logic of the script needs to be changed, because currently it distinguishes between a consultant and a non-consultant only basing on the OU where the user is created. If temp, intern, and consultants are located in the same OUs, there will be no way to distinguish whether it is a temp, an intern, or a consultant. Further:

Essentially, we like to be able to select an employee type and based on that, the user logon name pre win 2000, user logon name, and email to match while the user is filling out the form.
not sure if that's possible in real time(I changed the option to generate value on creating and editing obj but that didn't work for me or I'm misunderstanding it). or if its better created as a Business rule?

This can be done, but currently not in real time. You can create a Business Rule executed after creating a user. Depending on the employee type, the script will assign a proper username and e-mail for the user. For us to be able to change the script for you, can you tell us what property are you going to use to specify the employee type (will it be the Employee Type property or something else?) and what are the exact possible options for the property?

By the way, since the script will rely on the exact wording of a specific employee type, we recommend providing the list of possible employee types as a drop-down list, where an HR can pick an appropriate employee type. For information on how to specify a list of possible values for a property, see Specify List of Departments to Avoid Repetitive Typing.

commented Jan 8, 2014 by Support (216k points)

What option is/will be set for regular employees?

Currently for regular employees, we have Inter-Company Transfer, Permanent, Rehired Employee.

So, you want the user logon name and e-mail address to be generated completely automatically regardless of what the users enters? Are we getting you right?

No. I'd prefer what they choose as employee type for Consultants, Temp, and Interns to be reflected in logon name and email, i.e - intern.xx etc....For regular employees, it would be what we have now, firstInitialLastname and if that isn't unique, firstname.lastname.
Based on your previous response, I thought this couldn't be done b/c it can't happen during real time? So my concern/question is what the user sees when filling out the form in real time, if this is taking place within a Business rule before the account is created.

commented Jan 9, 2014 by MeliOnTheJob (1.7k points)

Hello,

Try this one:

$subject = "Account for %fullname% created"
$text = @"
New account created for user %fullname%.

Account details:
Username: %sAMAccountName%
Manager: %manager%
Department: %department%
Office: %physicalDeliveryOfficeName%

Please do not reply to this e-mail, it has been sent to you for notification purposes only.
"@

# Get the new user's manager
try
{
    $managerDN = $Context.TargetObject.Get("manager")
}
catch
{
    $Context.LogMessage("Cannot notify the manager's assistant because the user does not have a manager", "Warning")
    return
}
$manager = $Context.BindToObjectByDN($managerDN)

# Get the manager's assistant
try
{
    $assistantDN = $manager.Get("assistant")
}
catch
{
    $Context.LogMessage("Cannot notify the manager's assistant because the manager does not have an assistant", "Warning")
    return
}
$assistant = $Context.BindToObjectByDN($assistantDN)

# Get the assistant's e-mail
try
{
    $mail = $assistant.Get("mail")
}
catch
{
    $Context.LogMessage("Cannot notify the manager's assistant because the assistant does not have an e-mail address", "Warning")
    return
}

$Context.SendMail($mail, $subject, $text, $NULL)

In the script, $subject and $text specify the subject and the text of the email message. To insert information about the new user in the message, use value references (e.g. %username%).

commented Jan 15, 2014 by Support (216k points)

Hello,

FYI - I resolved...the $assistant was passing the $managerDN instead of the $assistantDN.

Thanks, a good catch. We've modified the script in the original post.

Why am I getting this and what would cause the account to not be logon enabled if its new?

The Create an Exchange mailbox action that is used in the built-in Create Exchange Mailbox Business Rule always creates user mailboxes, Exchange does not allow creating user mailboxes for those uses who cannot login to your domain (for example, disabled users). You can create an Exchange mailbox for a disabled user if you are creating an equipment or room mailbox, for example.

As you mentioned:

I also noticed that the account is being created as an disabled object

That's the main cause for the issue.

When a user is created as a disabled user, does there appear any Execution Log with a list of Business Rules triggered by the operation and actions performed by them? Can you send the Execution Log to our support e-mail (support[at]adaxes.com)?

Also, can you send us a copy of the log record for this operation? To do this:

Open the properties of the log record that represents the operation of creating a disabled user per step 7 of the following help article: http://www.adaxes.com/help/Logging.ViewServiceLogl.html.
At the top of the Properties dialog, right-click the description of the operation that is displayed next to an icon.
Click Select All.
Right-click again.
Click Copy.
Send the copied text to us.

commented Jan 21, 2014 by Support (216k points)

Hello,

Actually, it's ready. Here you are.

Import-Module Adaxes
$upnSuffix = "example.com" # TODO: Modify me

function IsUserNameUnique($username)
{
    $user = Get-AdmUser $username -erroraction silentlycontinue
    return $user -eq $Null
}

# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")

# Get employee type
$employeeType = $Context.GetModifiedPropertyValue("employeeType")
$usernameNotChanged = $True
if (-not([System.String]::IsNullOrEmpty($employeeType)))
{
    # Check the username if it does not contains the Employee Type, add it
    if (-not($username.StartsWith($employeeType , "CurrentCultureIgnoreCase")))
    {
        $username = "$employeeType.$username"
        $usernameNotChanged = $False
    }
}

# If the username is not unique, generate a unique one
$uniqueUsername = $username
for ($i = 1; $True; $i++)
{
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }
    $uniqueUsername = $username + $i;
    $usernameNotChanged = $False
}

# if the user name has not changed, exit
if ($usernameNotChanged)
{
    return
}

# Update User Logon Name (pre-Windows 2000)
$Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

# Update User Logon Name
$userLogonName = $uniqueUsername + "@" + $upnSuffix
$Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
$Context.LogMessage("The username has been changed to " + $userLogonName `
    + ".", "Information")

# Update email address
$mailAddress = "$uniqueUsername@$upnSuffix"
$Context.SetModifiedPropertyValue("mail", $mailAddress)
$Context.LogMessage("The email address has been changed to $mailAddress", "Information")

commented Jan 23, 2014 by Support (216k points)

hello--

A couple questions about the script--

1.The variable used $employeeType relates to my drop menu on the new hire form. However, does it matter that my label have a space?

2. On the action page, there's 2 sections. One for Permanent/Full time employers, which I have specific OUs for. The employee type drop down consist of Inter-company, Permanent, Re Hire.
For permanent accounts, you've supplied me with a script that will chk if the username is unique and if not, update it to be firstname.Lastname@domain.com, which is executed Business Rule before the account is created, and before the approval.

For the 2nd section on the action page, it's for consultants/interns/temp, with OUs specially for those as well. The employee type drop down has Consultants, interns, temps.
To make this affect only the consultants/temp/interns, I will have to make another Bus Rule before account creation and have it check what OU the account will reside, then add this script before the approval, right? or just add as a condition.

Also, in the script, when it checks to see if it unique, will it be adding a #1 to the unique name?
We'd prefer it to be employeeType.firstIntialLastName if it isn't unique. Can you update to reflect?

Thanks!

commented Jan 28, 2014 by MeliOnTheJob (1.7k points)

Hello,

1. In PowerShell scripts, you should use LDAP names of properties instead of their display names that are used in the Web Interface / Administration Console. employeeType is the LDAP name for the property that is displayed as Employee Type in the Web interface / Administration Console. As for $employeeType, it is a PowerShell variable. Actually, you can call it the way you like ($myValue, for example). We called it the same as the LDAP name for simplicity sake.

2. We think it would be better to launch the necessary script based on the value of the Employee Type property, for example:

For this purpose, you can use the If <property> <relation> <value> condition type.

Also, in the script, when it checks to see if it unique, will it be adding a #1 to the unique name?

No, if the username is already unique, the script will simply check whether the necessary prefix (for example, intern.) is added to the beginning to the username and add it, if necessary. If the username is unique and already contains the prefix, the script will leave it as it is.

commented Jan 28, 2014 by Support (216k points)

Ok, but what if an account already with the proper prefix?

On the current form, I hard coded consultant.%firstname:lower,1%%lastname:lower,1% for the user Logon name.
I just changed it to %employeeType%.%firstname:lower,1%%lastname:lower,1% and reflects the user Logon name! YAY! :D so that totally takes care of HR having to enter that. The script could now check to see that the samAccount is unique, and if not, add the the users lastname.

Thanks for the suggestion. Currently, I have the business rule setup to check if the user is apart of the HR and then execute the proceeding actions. This is kind of like my insurance in the event an issue comes up.
The activity scope is currently on all objects, which I will change to match same OUs the current user property pattern uses.
If I do the above, I think this just may satisfy the request.

commented Jan 28, 2014 by MeliOnTheJob (1.7k points)

Hello,

Here you are:

Import-Module Adaxes
$upnSuffix = "example.com" # TODO: Modify me

function IsUserNameUnique($username)
{
    $user = Get-AdmUser $username -erroraction silentlycontinue
    return $user -eq $Null
}

function SaveChanges($uniqueUsername, $upnSuffix)
{
    # Update User Logon Name (pre-Windows 2000)
    $Context.SetModifiedPropertyValue("samAccountName", $uniqueUsername)

    # Update User Logon Name
    $userLogonName = $uniqueUsername + "@" + $upnSuffix
    $Context.SetModifiedPropertyValue("userPrincipalName", $userLogonName)
    $Context.LogMessage("The username has been changed to $userLogonName.", "Information")

    # Update email address
    $mailAddress = "$uniqueUsername@$upnSuffix"
    $Context.SetModifiedPropertyValue("mail", $mailAddress)
    $Context.LogMessage("The email address has been changed to $mailAddress", "Information")
}

# Get the username
$username = $Context.GetModifiedPropertyValue("samAccountName")

# Get employee type
$employeeType = $Context.GetModifiedPropertyValue("employeeType")
$usernameChanged = $False
if (-not([System.String]::IsNullOrEmpty($employeeType)))
{
    # Check whether the username contains Employee Type
    if (-not($username.StartsWith($employeeType , "CurrentCultureIgnoreCase")))
    {
        $username = "$employeeType.$username"
        $usernameChanged = $True
    }
}

# Check if the username is unique
$uniqueUsername = $username
if (IsUserNameUnique($uniqueUsername))
{
    # Username unique, but Employee Type was added. Save the changes
    if ($usernameChanged)
    {
        SaveChanges $uniqueUsername $upnSuffix
    }
    return
}

# If the username is not unique, generate a unique one
$uniqueUsername = $NULL
$username = $NULL
if (-not([System.String]::IsNullOrEmpty($employeeType)))
{
    $username = "$employeeType."
}
$username += "%firstname:lower,1%%lastname:lower%"
$uniqueUsername = $username
for ($i = 1; $True; $i++)
{
    if (IsUserNameUnique($uniqueUsername))
    {
        break
    }
    $uniqueUsername = $username + $i;
}

# Save the changes
SaveChanges $uniqueUsername $upnSuffix

commented Jan 30, 2014 by Support (216k points)

hi-

I'm am testing the newly created script and it doesn't seem to be behaving as expected.
I located an account that already exist and created an account similar to it. It is sent to the approver, but within the approval form, the fields aren't being updated with a unique name.

I looked at the execution log and all the conditions are being checked:
For this particular test B.R. -'Create unique username-TEST', I took your advice and have it checking the employee type, but that seems to satisfy both conditions...

execution log:
Business Rules: 1 rule encountered while processing your request
'Create unique username-TEST': Run PowerShell script 'Enforce Pwd Policy' for the user
'Create unique username-TEST': Run PowerShell script 'Generate unique username and update respective fields for Regular Employees' for the user
'Create unique username-TEST': Send this operation for an approval.
Your request has been submitted for approval.
'Create unique username-TEST': Run PowerShell script 'Enforce Pwd Policy' for the user
'Create unique username-TEST': Run PowerShell script 'Generate Unique username for Consultans/Interns/Temps' for the user
'Create unique username-TEST': Send this operation for an approval.

I figured it was the order that I screwed up so I changed it. That too didn't help--
Business Rules: 1 rule encountered while processing your request
'Create unique username-TEST': Run PowerShell script 'Enforce Pwd Policy' for the user
'Create unique username-TEST': Run PowerShell script 'Generate Unique username for Consultans/Interns/Temps' for the user
'Create unique username-TEST': Send this operation for an approval.
Your request has been submitted for approval.
'Create unique username-TEST': Run PowerShell script 'Enforce Pwd Policy' for the user
'Create unique username-TEST': Run PowerShell script 'Generate unique username and update respective fields for Regular Employees' for the user
'Create unique username-TEST': Send this operation for an approval.

I also noticed that in the approval form, its showing the adm-customattributes instead of the friendly name, even though I restarted IIS a few times after adding them.

EDIT - I now see why the script is running for the employee type not being equal to whatever is selected. Logically, it does satisfy the other 2 conditions. So how can I distinguish between the 2?

commented Jan 30, 2014 by MeliOnTheJob (1.7k points)

error when creating user

Please log in or register to add a comment.

Please log in or register to answer this question.

1 Answer

Please log in or register to add a comment.

Related questions