2

When I create my new users every week, I execute this powershell scripts I put together. It has been working like a charm for 10 months, but as of last week started throwing this strange error:

Invoke-Command : Cannot bind parameter 'Name' to the target. Exception setting "Name": "The property value is invalid.
The value can't contain leading or trailing whitespace."
At C:\Users\sarah.sanderson\AppData\Local\Temp\3\tmp_e30b6ca9-683a-430b-a22e-af2ff6d9ddc1_oam3omxv.1wu\tmp_e30b6ca9-683
a-430b-a22e-af2ff6d9ddc1_oam3omxv.1wu.psm1:27952 char:29
+             $scriptCmd = { & <<<<  $script:InvokeCommand `

 + CategoryInfo          : WriteError: (:) [New-Mailbox], ParameterBindingException
    + FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Exchange.Management.RecipientTasks.NewMailbox
> 

My script is as follows:

$cred = Get-Credential Contoso\
$session = New-PSSession -ConfigurationName Microsoft.Exchange -  ConnectionUri http://Contoso-mbx/powershell -Credential $cred
Import-PSSession $session
Import-Module activedirectory


$Users = Import-Csv "C:\PSScripts\Create\users.csv" -header("lastname","firstame","program","password")
foreach ($User in $Users) 
{  
$OU = "OU=Users,DC=Contoso,DC=local"  
$Password = $User.password
$Detailedname = $User.Lastname + "," + " " + $User.firstname 
$UserFirstname = $User.Firstname 
$UserLastname = $User.LastName 
$SAM =  $UserFirstname + "." + $UserLastname 
New-Mailbox -UserPrincipalName $SAM@contoso.org -OrganizationalUnit $OU -Database "Mailbox Database 2" -Name $Detailedname -Password (ConvertTo-SecureString "Welcome1$" -AsPlainText -Force) -FirstName $UserFirstName -LastName $UserLastName -DisplayName $DetailedName -ResetPasswordOnNextLogon $true

}

According to the error, it has something to do with our exchange server, which is Server 2008 R2 running Exchange 2010, but there have been no changes made to it in the last 6 months. I can not figure out where I should even be looking to untangle this error. Any help would be greatly appreciated.

Snippet from lines 27950-58:

$clientSideParameters = Get-PSImplicitRemotingClientSideParameters $PSBoundParameters $True $scriptCmd = { & $script:InvokeCommand @clientSideParameters -HideComputerName -Session (Get-PSImplicitRemotingSession -CommandName 'New-Mailbox') -Arg ('New-Mailbox', $PSBoundParameters, $positionalArguments) -Script { param($name, $boundParams, $unboundParams) & $name @boundParams @unboundParams }`

  • 1
    Did you follow up the error by checking the records in the Name column in your CSV file to ensure there's no leading or trailing whitespace? – JayMcTee Nov 11 '15 at 14:58
  • Yes. I even went so far as to create a new CSV from scratch to make sure there were no leading or trailing white spaces. The problem seems to be with the exchange server or mailbox database rather than the CSV file. – Sarah Sanderson Nov 11 '15 at 15:38
  • What if your CSV file has just one row? – Colyn1337 Nov 11 '15 at 15:54
  • By default, the csv would need at least 2 rows, one for the header that described what each column has, and then the second row would have the name of the target person to create. But like I said, there are absolutely no leading or trailing whitespaces in my csv at all. – Sarah Sanderson Nov 11 '15 at 15:59
  • I'm sorry, I thought the need for headers would be implied. There's more going on here than first appears. The error you posted doesn't appear consistent with the script you've included. By trying with a single row of usable data it would eliminate a lot of outlier causes. – Colyn1337 Nov 11 '15 at 16:29
0

Powershell Script Troubleshooting

The script is clearly not liking your CSV input, or the way it is put together in your script.

Please run the Import-CSV line manually from an initialized PowerShell session:

$Users = Import-Csv "C:\PSScripts\Create\users.csv" -header("lastname","firstame","program","password")

From this, you can query individual elements of the imported array: $users[1].firstname, $users[2].program, etc.

I would also suggest testing out your $DetailedName logic to make sure this entity is put together properly.

Version of Exchange

Are you sure nothing changed in your Exchange environment? The -Name parameter of New-Mailbox changed in behavior between Exchange 2010 and Exchange 2013. Technet Ex 2010 Technet Ex 2013+

In Exchange 2010:

The Name parameter specifies the user's name. This is the name that appears in Active Directory Users and Computers. This is also the user name that appears in Recipient Properties on the User Information tab.

In Exchange 2013:

The Name parameter specifies the unique name of the mailbox. The maximum length is 64 characters. If the value contains spaces, enclose the value in quotation marks (").

It would seem your environment is behaving in the Exchange 2013 sense, where -Name is not as tolerant of spaces.

Edit

This is going to get confusing, but here it goes.

With write-host, I can get the output you need for the -Name parameter in New-Mailbox.

> $displayname = $lastname + ',' + ' ' + $firstname
> Write-Host $displayname
Doe, John
> Write-Host """$displayname"""
"Doe,John"

Result: The triple-double quotes ("x3) serve to encapsulate the value of $displayname in double quotes.

What I don't know is whether New-Mailbox will parse this correctly and strip the resulting quotes off the name when getting this input.

Something that didn't work is ' " ' (without spaces) to encapsulate the variable $displayname. This resulted in " Doe,John" with a leading space. (???)

| improve this answer | |
  • Yes, I am sure nothing has changed in the exchange environment, and it is definitely 2010. As for the CSV, why would it accept the structure for months and then suddenly stop working? The problem isn't that the script never worked, it's that it worked fine until the middle of last week. – Sarah Sanderson Nov 12 '15 at 17:06
  • No CUs were applied to Exchange...? that's really what I'm leaning toward here, with the indication of the "whitespaces not allowed" error. Can you attempt to encapsulate the $detailedname variable in quotes and see if that helps? I'm not even sure that's possible within a script. – blaughw Nov 12 '15 at 17:14
  • Wouldn't putting quotes around the whole of the $detailedname variable negate the quotes that are within it, namely the ones to add ","+" " to insert a comma and space in the detailed name? – Sarah Sanderson Nov 12 '15 at 17:55
  • I think you can get around that by following tips here: technet.microsoft.com/en-us/library/ee692790.aspx – blaughw Nov 12 '15 at 17:59
  • I'm now getting the error: Invoke-Command : Cannot bind parameter 'Name' to the target. Exception setting "Name": "The length of the property is t oo long. The maximum length is 64 and the length of the value provided is 174." + $scriptCmd = { & <<<< $script:InvokeCommand ` + CategoryInfo : WriteError: (:) [New-Mailbox], ParameterBindingException + FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Exchange.Management.RecipientTasks.NewMailbox after making the change $Detailedname = "$User.Lastname, $User.firstname" – Sarah Sanderson Nov 12 '15 at 18:46
0

Status Update- When checking for recent changes to the servers, I had been concentrating on the exchange server because that is where the problem seemed to be originating. However, when I looked at the windows updates on the primary domain controller, it had done a large number of security updates on 11/1 which was around the time the script broke. To test my theory that it was one of the updates that caused the problem, I went to one of our other DC's that did not have the recent updates, and the script executed perfectly fine. I am going to do some roll-backs on the updates on the primary DC to try and pin-point which update is causing the problems, and will post when I find out which one it is.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.