Newbie asking about updating cmdlets

This topic contains 3 replies, has 3 voices, and was last updated by Profile photo of Richard Siddaway Richard Siddaway 3 years, 5 months ago.

  • Author
    Posts
  • #11642
    Profile photo of William Davis
    William Davis
    Participant

    Hello to all, my situation is this, and it may or maybe not have an answer so I thought I better ask the Pro's. Hate to try to fix something that is not fixable.

    I have several boxes that are running Win 7 Pro and PS version 4.0. I also have one box that is a Win 8.1 machine, also running PS version 4.0. I have updated all the machines to version 4.0.

    I am studying Ed Wilson's PowerShell first steps book while waiting on Don Jones book PowerShell in a month of lunches. The Ed Wilson book uses Win 8 and PS Version 3.0 and when I try to run the same commands on the Win 7 Pro machines I find that those commands are not available in that platform.

    Is there anything that I can do to get all the machines to the same level, or am I stuck with a Windows OS Compatibility issue? Thanks for your time and help, I find that posting questions here is a great way to learn, and someday I hope to be able to help others also.

  • #11643
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    There are hundreds (if not thousands) of cmdlets that only exist on Windows 8 or later; Microsoft made a huge push for its products to have PowerShell modules between the releases of those two OSes. They're mostly based on new WMI / CIM namespaces and classes that don't exist on the older operating systems, and as such, there's no way to get them working.

    There's always a way to reproduce that behavior on older platforms, even if you're not using the same method. It's just usually not a simple as running a cmdlet that's already made for you, though there are some exceptions. For instance, cmdlets like Add-PrinterDriver are new to Windows 8, but the %systemroot%\system32\Printing_Admin_Scripts\en-us\prndrvr.vbs script has been around for years. It accomplishes the same thing using older WMI classes.

  • #11646
    Profile photo of William Davis
    William Davis
    Participant

    Thanks sir for such a timely response, I am to new to understand all that you explained but I think I do. You stated basically that there is an "Old School" ways to do what the NEW cmdlets do, but I would have to learn that "Old School" way. I will pursue that process if the need arises, as for now, I guess my option is to upgrade the OS's to use the newer teaching materials, or use my one and only Win 8 machine exclusively for this book. Kind of bad luck because I have a small domain setup that I was using to test the materials in the textbook, but those machines are all Win 7 Pro PS Version 4.0. Anyway, thanks to your knowledge I now what I can and cannot do, SALUTE!

    You would think that the Windows folks would make the versions\operating system backwards compatible, just my thoughts:) Onward, and Upward we go!

  • #11648
    Profile photo of Richard Siddaway
    Richard Siddaway
    Moderator

    The problem is porting the CIM classes back to earlier versions of Windows. This isn't feasible proposition, nor a cost effective one. In most the cases I can think of – one major exception being the DHCP cmdlets in Server 2012 – there is a way to perform the same task.

    With PowerShell 1.0 the only way to access AD was using the [adsi] type accelerator. When Windows Server 2008 R2 shipped we got Microsoft AD cmdlets. They were ported back to some earlier version of Windows but not all.

    You are in a similar position with the new cmdlets. Many of them rely on WMI classes that just aren't available for earlier versions. Not all functionality can be ported back to all versions – we'd never get any progress if that happened.

    I can't think of a scenario where new functionality is guaranteed to be ported back to earlier versions.

You must be logged in to reply to this topic.