Check out the most comprehensive, actively managed Lync blog roll in the known universe, your one-stop source for links to over 100 of the very best Lync blogs. Here you will also find weekly blog highlights and a feed for a dozen of the top blogs.
Lync Server Support Home
Top Lync Solutions RSS Feed
Microsoft Senior Support engineers walk you through real-life support cases, giving you an insider’s view into the systematic approach they use to troubleshoot Lync Server issues.
These short videos focus on specific tasks and show you how to accomplish them for Microsoft Lync Server 2010.
By Edwin Young
Last time, we looked at some curious behavior when running the New-CsAnalogDevice cmdlet: when you leave out a mandatory parameter like AnalogFax, then PowerShell prompts you for it; but weirdly, even if you enter $false, the property ends up true. Why is that?
This isn’t strictly about special characters, but it’s due to a difference between how PowerShell interprets arguments passed “normally” on the command line, and arguments it prompts for. On the command line, everything is fully parsed and interpreted, but prompts are just treated as strings. It’s as if you ran
New-CsAnalogDevice –AnalogFax '$false'
Which would also end up with AnalogFax as $true, because any non-empty string, including “0”, “$false”, and “false”, evaluates as true. So if you do get prompted for a Boolean value and you want to set it to false, you can just hit Enter when prompted for that variable – this resolves to an empty string, which evaluates to $false.
This is deliberate, if rather surprising, behavior on PowerShell’s part. The thing to remember is that when you enter values in response to a prompt, they will be treated as if you surrounded them with single quotes.
Another example might make it clearer:
PS > Set-Content -Path foo.txt
cmdlet Set-Content at command pipeline position 1
Supply values for the following parameters:
PS > more .\foo.txt
PS > Set-Content -Path foo.txt -Value (1+1)
Here, 1+1 is evaluated on the command-line, but not when prompted for.
Finally, here’s a problem you can hit when you use the command line, but not when you are prompted.
PS > New-CsAnalogDevice -LineUri tel:+14257270002 -RegistrarPool pool1.contoso.com -AnalogFax $false -Gateway 192.168.0.240 -OU OU=AnalogDevices,DC=contoso,DC=com
Produces the message:
New-CsAnalogDevice : Cannot convert 'System.Object' to the type 'Microsoft.Rtc.Management.AD.OUIdParameter' required by parameter 'OU'. Specified method is not supported.
Why is that? Well, PowerShell uses commas to form arrays, so OU=AnalogDevices,DC=contoso,DC=com is actually treated as an array of three strings: "OU=AnalogDevices", “DC=contoso" and "DC=com". Since the cmdlet expects only a single string, PowerShell complains that the type of the input is wrong. To avoid this, just quote the string:
PS > New-CsAnalogDevice -LineUri tel:+14257270002 -RegistrarPool pool1.contoso.com -AnalogFax $false -Gateway 192.168.0.240 -OU "OU=AnalogDevices,DC=contoso,DC=com"
Anyway, these are the most common confusions I’ve seen arise due to PowerShell’s quoting and parsing behavior. I hope it saves you some time!
I also hope I haven’t made it sound too alarming – it’s really fairly straightforward once you get used to it. Happy scripting!