Showing posts with label Powershell V4. Show all posts
Showing posts with label Powershell V4. Show all posts

Sunday, February 18, 2018

Using Azure PowerShell and PowerShell 3 or 4? You need to update PowerShell SOON (probably).

I recently saw a GitHub Pull Request (https://github.com/Azure/azure-powershell/issues/5149) for the Azure PowerShell cmdlets (the PR was merged into Version 5.3.0 of the Azure cmdlets). Besides from the continuing improvements that each version brings, I noted one very interesting sentence: 'PowerShell version 3 and 4 will no longer be supported starting in May 2018. Please update to the latest version of PowerShell 5.1 '

What does this mean? Well – it means that after May this year, if you are running either PowerShell V3 or V4, new versions of the Azure cmdlets may not longer work – and are not supported in any case. That is not to say that either the sky is going to fall in! Older versions of the cmdlets should continue to work and most of the newer cmdlets should work too. Note the ‘should’. But why take the risk. You have several months before the lack of support begins. But you should start to plan now if you are still using PowerShell V3 or V4 to manage Azure.

So what should you do? The answer should be fairly obvious – if you are using Azure and the Azure cmdlets, just upgrade to the latest version of PowerShell (i.e. 5.1). This new version of PowerShell should work just fine on all supported versions of Windows. Of course, if you are still using XP to manage Azure then you may have some issues trying to upgrade, although an OS upgrade to Windows 10 would fix this problem.

The upgrade of PowerShell should be a no brainer. I suspect many (most?) readers here are already running later versions!  There should be no issue, but if you are using Exchange, tread carefully to ensure that the version of PowerShell you are thinking of upgrading to is going to work with and is supported by your version of Exchange.  This is probably not going to be an issue if you using hosted Exchange (O365).

It seems to me that this is the start of removing all support for PowerShell V3 and V4. V5 and V5.1 are sufficiently better to make the upgrade most welcome. Loads more cmdlets, improvements in workflows etc are all goodness that comes from the Upgrade.

What is your take?

Tuesday, November 25, 2014

Writing Classes With PowerShell V5 – Part 2

In a previous article, I set out what a class was and what it contains, and showed examples of using those classes in your PowerShell scripts. As I mentioned last time, you should use cmdlets where possible to create and manage objects. But when you can't you can always delve into the .NET Class Framework and it's huge class library.
But what if there are no applicable .NET objects and you need to create your own class? Some admins might be asking: why bother? The answer is one of flexibility and reuse. If you are writing scripts to automate your day to  day operations, you are inevitably passing objects between scripts, functions, cmdlets. There are always going to be cases where you'd like to create your own object simple as a means of transporting sets of data between hosts/scripts/etc.
In PowerShell V5, Microsoft has included the ability to create your own classes. When I started writing this set of articles, I had initially intended to just introduce Classes in V5, but as I looked at it, you can already create your own objects using earlier versions of PowerShell. These are not fully fledged classes, but are more than adequate when you just want to create a simple object to pass between your scripts/functions.
Creating Customised Objects
There are several ways you can achieve this. The first, but possibly hardest for the IT pro: use Visual Studio, author your classes in C# then compile them into a DLL. Then in PowerShell, you use Add-Type to add the classes to your PowerShell environment. The fuller details of this, and how to speed up loading by using Ngen.Exe are outside the scope of this blog post.
Bringing C# Into PowerShell
Now for the semi-developer audience amongst you, there's a kind of halfway house. In my experience, IT pros typically want what I call data-only classes. That is a class that just holds data and can be exchanged between scripts. For such cases, there's a simple way to create your class, although It does require a bit of C# knowledge (and some trial and error).
Here's a simple example of how to so this:
Add-Type @' 
public class Aeroplane
   {
     public string Model = "Boeing 737";   
     public int    InFleet = 12;
     public int    Range = 2400;
     public int    Pax   = 135;
   } 
'@
This code fragment defines a very small class – one with just 4 members (Model, number in fleet, range, and max number of passengers).  Once you run this, you can create objects of the type AeroPlane, like this:
image
As you can see from the screen shot, you can create a new instance of the class by using New-Object and selecting your newly created class.
If you are just creating a data-only class – one that you might pass from a  lower level working function or script to some higher level bit of code – then this method works acceptably. Of course, you have to be quite careful with C# syntax.  Little things like capitalising the token Namespace or String will create what I can only term unhelpful error messages.
Using Select-Object and Hash Tables
Another way to create a custom object is to use Select-Object. Usually, Select object is used to subset an occurrence – to just select a few properties from an object in order to reduce the amount of data that is to be transferred. In some cases, this may be good enough and would look like this:
Dir c:\foo\*.ps1 | Select-Object name,fullname| gm
  TypeName: Selected.System.IO.FileInfo
Name        MemberType   Definition                                  
----        ----------   ----------                                  
Equals      Method       bool Equals(System.Object obj)              
GetHashCode Method       int GetHashCode()                           
GetType     Method       type GetType()                              
ToString    Method       string ToString()                           
FullName    NoteProperty System.String FullName=C:\foo\RESTART-DNS.PS1
Name        NoteProperty System.String Name=RESTART-DNS.PS1          
Note that when you use Select-Object like this, the object's type name changes. In this case, the dir (Get-ChildItem) cmdlet was run against the File Store provider and yielded objects of the type: System.Io.FileInfo. The Select-Object, however, changes the type name to SELECTED.System.IO.FileInfo (emphasis here is mine). This usually is no big deal, but it might affect formatting in some cases. 
But you can also specify a hash table with the select object to create new properties, like this:
PSH [C:\foo]: $Filesize = @{
    Name = 'FileSize   '
    Expression = { '{0,8:0.0} kB' -f ($_.Length/1kB) }
}

Dir c:\foo\*.ps1 | Select-Object name,fullname, $Filesize
Name                   FullName                  FileSize               
----                   --------                  -----------               
RESTART-DNS.PS1       C:\foo\RESTART-DNS.PS1         1.1 kB               
s1.ps1                C:\foo\s1.ps1                  0.1 kB               
scope.ps1             C:\foo\scope.ps1               0.1 kB               
script1.ps1           C:\foo\script1.ps1             0.5 kB               

PSH [C:\foo]: Dir c:\foo\*.ps1 | Select-Object name,fullname, $Filesize| gm
   TypeName: Selected.System.IO.FileInfo
Name        MemberType   Definition                                  
----        ----------   ----------                                  
Equals      Method       bool Equals(System.Object obj)              
GetHashCode Method       int GetHashCode()                           
GetType     Method       type GetType()                              
ToString    Method       string ToString()                           
FileSize    NoteProperty System.String FileSize = 1.1 kB       
FullName    NoteProperty System.String FullName=C:\foo\RESTART-DNS.PS1
Name        NoteProperty System.String Name=RESTART-DNS.PS1          
As you can see form this code snippet, you can use Select-object to create subset objects and can extend the object using a hash table. One issue with this approach is that the member type for the selected properties (the ones included from the original object and those added) become NoteProperties, and not String, or Int, etc. In most cases, IT Pros will find this good enough.
In the next instalment in this series, I will be looking at using New-Object to create a bare bones new object and then adding members to it by using the Add-Member cmdlet and how to change the generated type name to be more format-friendly.

Saturday, January 18, 2014

More Desired State Configuration Resources

On Boxing Day, the PowerShell team at Microsoft released some additional DSC (Desired State Configuration) resources, which they call the DSC Resource Kit Wave 1. These are as et of PowerShell moduels that contain both DSC Resource and sample configuration examples.

Microsoft initially shipped a number of built in resources for DSC (described on TechNet: here) as well as the ability to create your own custom resources (this is documented here).

The DSC Resource kit contains 8 new resources as follows:

 

Resource Description
xComputer Name a computer and add it to a domain/workgroup
xVHD Create and managed VHDs
xVMHyperV Create and manage a Hyper-V Virtual Machine
xVMSwitch Create and manage a Hyper-V Virtual Switch
xDNSServerAddress Bind a DNS Server address to one or more NIC
xIPAddress Configure IPAddress (v4 and v6)
xDSCWebService Configure DSC Service (aka Pull Server)
xWebsite

Deploy and configure a website on IIS

 

If you want to use the DSC Resource Kit you need to be running Windows 8.1 or Windows Server 2012 R2 with update KB2883200 (aka the GA Update Rollup).

DSC is an amazing feature of PowerShell 4, which just got even better!

Technorati Tags: ,

Thursday, January 16, 2014

Poshlinks.Com–PowerShell Links Galore

I just stumbled upon poshlinks.com, a PowerShell link list – a page full of links to more information about PowerShell and other stuff. At present there are over 1100 separate links to a variety of PowerShell related content. You can find links on fundamentals such as objects and modules, links related to using PowerShell with applications such as Lync, and a whole lot more.

So far, I’m not clear on how to add more to this list, but if/when I find out, I’ll blog it. I the meantime, this is a great resource and I’m going to be busy checking out all the links!

Technorati Tags:

Friday, November 29, 2013

What’s New in PowerShell V4

I get the occasional query as to what is new in PowerShell 4. For the most part, the key update is the addition of Desired State Configuration plus a bunch of bug fixes. But there is a lot more, as you can see in the What’s New help file: http://technet.microsoft.com/en-us/library/hh847833%28v=wps.630%29.aspx?_=1385725589770.

The biggest new feature is DSC, desired state configuration. DSC enables the deployment and management of configuration data for software services and the environment in which these services run. DSC is a great feature, but as it stands in V4 is not really complete. It needs more work, and specifically needs some tooling to make specifying DSC easier and a lot more straightforward. No doubt this is coming in V5 – we’ll see.

In addition to a number of new features, V4 brings a bunch of bug. Interestingly, the bug fix I like most is not mentioned: In V3, CIM based cmdlets (cmdlets defined using CDXML) did not properly add the noun and verb to the command’s System.Management.Automation.CmdletInfo object. That is now fixed.

Sadly, V4 does not run on Windows 8 which many continue to think is daft. But the folks in Redmond clearly know more than I do about this stuff and there must be great reasons. Given that PowerShell V4 runs on Server 2012, it should run just fine on Windows 8. For me, this means I can’t take advantage of V4 on a couple of machines as I just do not have the time to downgrade to Windows 7 or upgrade to 8.1.

Technorati Tags: ,

Wednesday, July 03, 2013

PowerShell V4 Beta is available

The beta of PowerShell’s next version has been released. PowerShell version 4 will ship as part of the Windows Management Framework components built into Windows 8.1 and Server 2012 R2. WMF4 will also be made available for some down-level OSs, including Windows 8, Server 2008, Server 2008 R2 and Server 2012.

Interestingly, WMF4/PowerShell V4 will not ship for Windows 8. For reasons I’m not quite clear, Microsoft believe that Windows 8 and 8.1 are interchangeable in all environment (thus anyone running 8 now will very quickly upgrade to 8.1 and anyone planning to roll 8 out now can simply reset their plans for 8.1). I can’t quite work out why they believe it, but I’m sure they have loads of paid volunteers willing to tell them that.

The new WMF had 5 key features:

  • Windows PowerShell  Version 4
  • Windows PowerShell Integrated Scripting Environment (ISE) Version 4
  • Windows PowerShell Web Services (Management OData IIS Extension)
  • Windows Remote Management (WinRM) and PS Remoting V2.2
  • Windows Management Infrastructure (WMI) (Windows Management Instrumentation appears to have a new name AND some new features).

You can read more details on the PowerShell Team Blog: http://blogs.msdn.com/b/powershell/archive/2013/07/02/windows-management-framework-4-0-preview-now-available.aspx

Technorati Tags:

Tuesday, July 02, 2013

PowerShell V3 Modules–Updated Help information

PowerShell V3 comes with a key feature: Updateable help. There is virtually no help shipped, ‘in the box’, but with the Update-Help cmdlet, you can download help for PowerShell core and for any module you have loaded on your system. This approach enables Microsoft to update help information without users having to wait for the next release of PowerShell. Not shipping Help in the box was always, to me, a daft way of going about it, but it was the only way we could get updateable help.

That’s the good news. The bad news is that in the recent past, there was a bug in the team’s build tools that led to all the data types of parameters to be missing from the Syntax block at the top of the Get-Help output. This information was still listed in the parameter descriptions shown by Get-Help -Full and Get-Help –Detailed. This may not have been a huge issue but for those of us who teach the discoverability aspects of PowerShell, it was yet another bug to work around.

Thankfully those nice folks at WSIX have found and fixed the bug and have rolled out new Help Information as of today. In all, 12 modules have had updated help published: CimCmdlet, Hyper-V, IScsi, Microsoft.PowerShell.Core, Microsoft.PowerShell.Management, Microsoft.PowerShell.Utility, MMAgent, PSScheduledJob, PSWorkflow, PSWorkflowUtility, ServerManager, and WindowsServerBackup.

At the time of writing, help for Windows Server Essentials 2012 and the pre-release modules for Server 2012 R2, Windows 8.1 and PowerShell v4 has not been updated, although Microsoft are working hard to get the fixes out. Hopefully by the time you read this, these modules too will be fixed.

Updateable help has proved it’s worth this time around. And while the error is certainly regrettable, such things do happen and thankfully, we now have a way to get this information fixed before the next version of Windows!