This topic contains 3 replies, has 3 voices, and was last updated by
November 24, 2013 at 5:40 am #11642ParticipantTopics: 4Replies: 5Points: 0Rank: Member
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.
November 24, 2013 at 6:00 am #11643MemberTopics: 9Replies: 2322Points: 0Rank: Member
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.
November 24, 2013 at 6:46 am #11646ParticipantTopics: 4Replies: 5Points: 0Rank: Member
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!
November 24, 2013 at 9:56 am #11648ParticipantTopics: 0Replies: 669Points: 0Rank: Member
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.
The topic ‘Newbie asking about updating cmdlets’ is closed to new replies.