No good way of emptying/clearing an attribute value about mimpowershellconnectors HOT 4 CLOSED

If you look at the code in the Export script, currently, it will not clear the LineURI so only update with something else will work. Also looking at the code it should be able to clear ConferencingPolicy. What are the exact cmdlets to fire to clear these? May be we need a bit of revision to the code.

from mimpowershellconnectors.

I checked out the Invoke-SetCsUserCommand function and it contains really bad coding practices, the option of flowing Null has defenately been foreseen.
To start with, there is no reason what so ever building the command as a string for calling Invoke-Expression, splatting the parameters to the command would be far better and it would allow flowing null values.

As a quick fix for being able to clear the LineUri was to change this line that currently doesn't accept flowing null:
if ($lineURI -ne $null) { $cmd += " -LineURI '$lineURI'" }
...into:
if ($null -eq $lineURI) {$cmd += ' -LineURI $null'}else{ $cmd += " -LineURI '$lineURI'"}

The function Invoke-GrantCsPolicyCommands has an equally crappy implementation, string commands created and executed with Invoke-Command. For example if passing a null value using Invoke-Expression and this line:
if ($conferencingPolicyChanged) { $cmd += " | Grant-CsConferencingPolicy -PolicyName '$conferencingPolicy' -PassThru" }
...Will result in this when flowing Null:
Grant-CsConferencingPolicy -PolicyName '' -PassThru
...and not:
Grant-CsConferencingPolicy -PolicyName $null -PassThru
...We already have a fix for this and that was to add the default policy as a named policy and flow the name of that policy however that was before I realized these functions has such a crappy implementation.

Flowing null as ConferencingPolicy will of course give us an "exported-change-not-reimported" warning since the import will return an empty string and not Null however the biggest problem is that and empty string probably wont enable the default Policy.

I think both of these methods needs to be fixed with better coding practices and the possibility to flow null values where allowed.

from mimpowershellconnectors.

@Identitry, the current coding style is due to two design goals: 1. The codebase when written was meant for PowerShell 2.0, no splatting there. The other goal was to be able to debug on demand in a live production environment what exact command is being executed hence the creation of string first. You simply turn debugging on or on via the sync config file as and when there is a need for troubleshooting. Lot of things have changed over the years. Now the PowerShell connector shipped with the product works with .NET 4.5 and so supports PowerShell 3.0+, so you are welcome to upgrade the scripts with PowerShell 3.0+ capabilities as long as we can also meet the second goal as well. Let me know if you sign up for this and I'll add you as a contributor to the project, else I'll just close this issue now that you quick-fixed it for yourself.

from mimpowershellconnectors.

Hi, I'm closing this issue as waiting for someone to invest their time to do script upgrade to PSH 3.0 and beyond if they are strongly convinced that there is definite ROI on this effort.

from mimpowershellconnectors.