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 }`

Sarah Sanderson
  • 51
  • 7
  • 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
  • OK, I just tried running it with only 1 user for creation, but it still kicked back the same error. I also tried running the script after removing the -name parameter from the script. It spit out the same error, with the exception of then prompting me to supply a -name parameter, so I don't think it has anything to do with setting the detailed name. – Sarah Sanderson Nov 11 '15 at 16:34
  • It's odd that it would be exact. Is this section exactly the same? 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 – Colyn1337 Nov 11 '15 at 16:40
  • Script tmp_a5dafe38-9025-450d... {Get-IRMConfiguration, New-MailUser, Enable-CmdletExtensionAgent, New-Ac... 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_a5dafe38-9025-450d-b5b2-00d3ffe02248_wyr0ivr2.hng\tmp_a5dafe38-902 5-450d-b5b2-00d3ffe02248_wyr0ivr2.hng.psm1:27952 char:29 – Sarah Sanderson Nov 11 '15 at 16:52
  • + $scriptCmd = { & <<<< $script:InvokeCommand ` + CategoryInfo : WriteError: (:) [New-Mailbox], ParameterBindingException + FullyQualifiedErrorId : ParameterBindingFailed,Microsoft.Exchange.Management.RecipientTasks.NewMailbox – Sarah Sanderson Nov 11 '15 at 16:52
  • open up the file indicated and drop down to line 27952. Copy the relevant code before and after that line and add it to your question. The code on line 27952 is the offender triggering the exception. – Colyn1337 Nov 11 '15 at 18:46
  • Since the original error is clear (it's objecting to leading/trailing whitespace in the value for Name) it would be useful to examine/display the value just before it is passed to the function. Something as simple as `"--"+$DetailedName+"--"` (markers either side of string to make spaces obvious). If that looks OK then could another definition of New-Mailbox have been introduced to the environment? `(get-command New-Mailbox).definition` might help. – Paul Haldane Nov 12 '15 at 08:05
  • Snippet 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 }` – Sarah Sanderson Nov 12 '15 at 14:02
  • Could you add that to your question? It looses formatting in the comments. Also, try executing your script from a different profile or a different machine (one that's never executed this script before). Did you recently update the exchange tools installed on your machine? – Colyn1337 Nov 12 '15 at 19:11

2 Answers2

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. (???)

blaughw
  • 2,267
  • 1
  • 11
  • 17
  • 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: https://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
  • I can get this to come correct using `write-host`, hopefully it will work when passing to a real command. I'm editing my answer now. – blaughw Nov 12 '15 at 19: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.

Sarah Sanderson
  • 51
  • 7