PowerShell Trim – no its not a new slimming fad. Trimming is the act of removing characters – usually white space – from the beginning or end of a string.
You have three methods on the String class you can use
PS> $str = ” abcdefghijk ”
You can also trim specific characters from the beginning or end of a string
PS> $str = “.,:abcdefghijk:,.”
PS> $tc = [char]’.’, [char]’,’, [char]’:’
You should now be able to handling any string trimming required in your code
PowerShell works great when you use it interactive;y but at some point you’re likely to want to write substantial pieces of code – scripts or functions – for which you’ll need an editor. This is my take on PowerShell editors.
There are PowerShell add-ins for Visual Studio – one of the best is PowerShell Tools by Adam Driscoll: https://marketplace.visualstudio.com/items?itemName=AdamRDriscoll.PowerShellToolsforVisualStudio2017-18561
If you’re working with Visual Studio already and need to add PowerShell to your project then this is a good option. if you’re only creating PowerShell code then Visual Studio has too much overhead.
PowerShell ISE (Integrated Scripting Environment) was introduced with PowerShell v2. Its gone through a number of updates with subsequent versions of PowerShell. It’s the tool I normally use. It supplies access to the debugger and happily runs across a number of PowerShell runspaces. You can use it to run and debug code on remote machines.
ISEs drawback is that its Windows only and it isn’t part of PowerShell v6.
As far as I can tell all of the editor related development work is going into VSC (Visual Studio Code) https://code.visualstudio.com/. VSC is a lightweight editor like ISE but can also work with a large number of other languages. You can tailor VSC by only downloading those extensions you need. I have extensions for PowerShell, JSON, XML MSSQL, markdown and Docker among others.
VSC has good debugging tools. I do miss the ability to run selected lines of code like ISE. I’ll be sticking with ISE for demos for now.
VSC has the advantage that its available for Windows and Linux (and mac) so you can use the same editor cross platforms if need be.
There are other products you can consider. ISE Steroids (from the PowerShell studio) is a great add-in for ISE. Sapien have tools such as PowerShell Studio and Primal Script. Idera have PowerShell Plus. These and other tools have to be paid for.
So what editor should you use.
ISE is great for Windows only environments. If you need cross-platform or multi-language consider VSC.
I use ISE but I’m increasingly turning to VSC as that seems to be getting the development effort and evolving very quickly with updates most months.
The call for topics is closing 1 October at 23:59 GMT. We’ve had a fantastic set of submissions. Creating an agenda for the 2018 Summit is going to be very difficult because we’ve had so many fantastic sessions submitted and I don’t have enough slots to take them all.
The call for topics is hosted by papercall.io – highly recommended – and the cut off is automatic.
I WILL NOT ACCEPT ANY SESSIONS SUBMITTED AFTER THE CUT OFF DATE.
I was incredibly excited when I first saw DSC – it was in April 2013 as a special MVP only preview at the first PowerShell Summit – as a work in progress. Since that time my excitement has waned to the point that I now ask DSC – the future?
Looking at the PowerShell Team announcement about the introduction of DSC core – https://blogs.msdn.microsoft.com/powershell/2017/09/12/dsc-future-direction-update/
I have to question if a complete new version of DSC is worth my time investigating especially when backward compatibility isn’t guaranteed.
Don Jones has question where DSC is going – https://powershell.org/2017/09/13/the-future-of-powershells-desired-state-configuration/
Overall, I’d say that DSC has had a mixed success since its introduction due to changes and the difficulty around preforming some activities. The integration with Azure hasn’t been smooth.
Is it time to look at another configuration tool set. Microsoft’s current rush to embrace Linux may make Chef or Puppet a better option for you. Read the comments on the PowerShell Team announcements to see what other people think about DSC.
Putting comments into your code has been a long established practice – this is how you do PowerShell comments
A single line comment is indicated by the # symbol
# This is a comment
You can put a comment at the end of a line but not in the middle. Once you’ve added a comment that’s it for the rest of the line
Get-Process # This is a comment
In ISE and Visual Studio Code comments are shown in green by default
You can also create multi-line comments
Be careful if you use # symbols in file names or other data in PowerShell – you may end up with PowerShell thinking you’ve declared a comment
Microsoft has announced a continuous updates expansion at Ignite
Windows 10 was always going to be continually updated rather than new versions introduced.
This year Windows Server 2016 joined the party when it was announced that there would be twice yearly updates – Windows 10 moved to the same cadence.
At Ignite Microsoft announce that a number of other products would join the continuous update party including:
Office 2019 – should see it in second half of 2018
Skype for Business
Assuming they join the twice yearly updates – NOTE these are not patches but new features or changes – cadence that the OS teams have adopted this is going to bring interesting times for operations staff.
On the plus side the need to roll out completely new builds of workstations goes away because you’re not going to get a new OS in a few years.
On the negative side you’re going to have to develop a strategy for dealing with new feature releases on a perhaps twice yearly basis, You can put off, for a time, these particular updates but life will start to get very messy very quickly unless you freeze all feature updates. – Bet your users will be clamouring for the updated features.
This change is 1-2 years off but you need to start thinking about how you’re going to handle it NOW otherwise you’ll have a very complicated environment that becomes more difficult to manage with time.
Saw an interesting question on splitting multiline string
If you get a set of strings
emailed to you then you could put them in a text file and use Get-Content to read them into an array. The question was could you paste them into PowerShell and get the same effect.
Not sure if this is the easiest way but it works
PS> $x = @’
‘@ -split “`n”
A number of my PowerShell books including PowerShell in Action and PowerShell in Depth will be part of Manning’s Deal of the Day on 29 September 2017
Use code dotd092917au at http://bit.ly/2hzetVX
For DoD details see https://www.manning.com/dotd
Following my last post I was asked about these Examples of replacing WMI cmdlet with CIM cmdlet.
gwmi win32_operatingsystem -computername $Computer -credential $creds,
$cs = New-CimSession -Credential $creds -ComputerName $computer
Get-CimInstance -ClassName Win32_operatingsystem -CimSession $cs
get-wmiobject -query “SELECT * FROM Meta_Class WHERE __Class = ‘Win32_Process’” -namespace “root\cimv2” -computername $computer -credential $creds
$cs = New-CimSession -Credential $creds -ComputerName $computer
Get-CimInstance -Query “SELECT * FROM Meta_Class WHERE __Class = ‘Win32_Process’” -CimSession $cs
Get-WmiObject -Namespace $namespace -Class SMS_fullcollectionmembership -ComputerName $SCCMServer -filter “Name = ‘$computer’” -credential $creds
$cs = New-CimSession -Credential $creds -ComputerName $SCCMServer
Get-CimInstance -Namespace $namespace -ClassName SMS_fullcollectionmembership ” -filter “Name = ‘$computer’” -CimSession $cs
I still see a lot of people using the WMI cmdlets – Get-WmiObject etc. You really should be using CIM nit WMI. In other words use Get-CimInstance rather than get-WmiObject etc etc.
Why do I say that?
Two main reasons.
Firstly, the WMI cmdlets are effectively deprecated. Any further development effort will be for the CIM cmdlets.
Secondly, and to my mind more important, is that the CIM cmdlets use WS-MAN for access to remote machines. If you have PowerShell remoting enabled you have access to the machine via a CIM session – either ephemeral using the cmdlet name or persistent using a CIM session.
The WMI cmdlets use DCOM for remoting which is blocked by default on the Windows firewall and most other firewalls and routers giving the RPC server is unavailable error.
The only time there is justification for using the WMI cmdlets is if you’re on a machine that has Powershell v2 installed and if that’s the case why haven’t you upgraded? If you can’t does that mean you’re running an application (usually Exchange or System Center) that doesn’t allow you to upgrade PowerShell.
Maybe its time to perform that upgrade.
As another thought PowerShell v6 includes the CIM cmdlets but not the WMI cmdlets!