PowerShell 6.0 Plan

[joeyaiello]

This is a preliminary, WIP roadmap/plan for what we on the @PowerShell/powershell-committee believe needs to be in a PowerShell 6.0 release. We will be iterating on this significantly based on your feedback, as well as potentially shifting internal priorities. The goal is for all line items here to eventually be represented by issues attached to either the 6.0.0 or 6.0.0-beta milestones, so that you anyone can look in and see how far along we are towards a 6.0 release.

I also plan on publishing a blog to break down our plans in more detail sometime soon. In the meantime, please join us on the PowerShell Core Community Call tomorrow @ 9am PST where we'll be talking about this in more detail.

If you believe we're missing something here that's absolutely critical for the 6.0 release, please let us know below in the comments or on our monthly Community Call. Thanks!

[cut] means something we've decided is not required to ship 6.0.0 final and we'll address in a future release (not that it's cut forever)

• [ ] Everything in the 6.0.0-HighPriority milestone
• [ ] [Test coverage](https://coveralls.io/github/PowerShell/PowerShell?branch=master)
  
  
  
  • [x] Identified test gaps fixed
  
  
  • [x] Un-hit code coverage analyzed and understood
  
  
  • start here
  
  
  • [ ] Cross-platform, cross-machine remoting tests #2436
  
  
  • [x] https://httpbin.org/ is unreliable for web requests testing #2504
  
  
• [x] sudo support
  
  
  
  • [x] sudo <native command> should work from within PowerShell
  
  
  • [cut] sudo <PowerShell cmdlet> should work from within PowerShell #3232
  
  
  • [cut] Misc sudo bugfixes
    
    
    
    
    
    • [cut] sudo command does not work in remote session to Linux machine #1527
    
    
    
  
  
• [x] Native globbing support #954
• [x] Jobs
  
  
  
  • [x] Start-Job #452
  
  
  • [x] Other *-Job cmdlets #3110
  
  
  • [cut] Job control (bg, fg with &) #716
    
    
    
    
    
    • [cut] Ctrl+Z support #3229
    
    
    
    • [x] bg jobs #1972
    
    
    
  
  
• [x] Native/binary pipeline support #559 #2450
• [x] Figure out aliases #929
• [ ] Other cross-platform usability issues
  
  
  
  • [ ] Filesystem-specific case sensitivity #3218
  
  
  • [x] Cross-platform encoding usability #707
  
  
  • [X] Fix screen issues #2364
  
  
• [ ] "Cloud-ready"
  
  
  
  • [x] awesome ConvertFrom/To-Json
    
    
    
    
    
    • [x] ConvertFrom-Json does not respect -ErrorAction #2860
    
    
    
    • [x] Use prettier formatting for ConvertTo-Json #2736
    
    
    
    • [x] Convertto-Json and url encoding #2632
    
    
    
    • [x] ConvertFrom-Json and ConvertTo-Json eat the one object array #2448
    
    
    
    • [cut] ConvertFrom-Json fails to parse project.lock.json #1755
    
    
    
    • [x] ConvertFrom-Json keys collision: behavior difference between Core and Full #1567
    
    
    
  
  
  • [X] awesome Invoke-RestMethod/Invoke-WebRequest
    
    
    
    
    
    • [x] Fix IE dependency for Invoke-WebRequest #3042
    
    
    
    • [x] Invoke-WebRequest: Vague error thrown, resulting from TLS issue #2942
    
    
    
    • [cut] Invoke-WebRequest / Invoke-RestMethod fails to follow HTTP redirects #2896
    
    
    
    • [x] invoke-webrequest and invoke-restmethod -headers parameter is more restrictive ... #2895
    
    
    
    • [cut] Invoke-Webrequest is missing some properties, like .ParsedHtml and .AllElements #2867?
    
    
    
    • [x] Invoke-WebRequest throw TypeInitializationException On Linux #2801
    
    
    
    • [x] InFile parameter of Invoke-WebRequest doesn't work #2754
    
    
    
    • [x] Invoke-RestMethod does not count on Content-Type field. Broken compared to PS 5.0. #2245
    
    
    
    • [x] Invoke-RestMethod does not strip Authorization Headers #2227
    
    
    
    • [x] Invoke-RestMethod should return the full error response from the remote endpoint #2193
    
    
    
    • [x] WebRequestPSCmdlets do not contain Response object in Exception on Mac OS X #2113
    
    
    
    • [x] Invoke-Webrequest accepts bad TLS certificates / crypto on MacOS #1942
    
    
    
    • [x] Missing command alias: iwr #1778
    
    
    
    • [x] Invoke-WebRequest does not support -TransferEncoding deflate #1753
    
    
    
    • [x] Add tests case for invoke-restmethod/webrequest, and move the rest of the tests ... #1532
    
    
    
  
  
• [ ] Remoting
  
  
  
  • [ ] PSRP over OpenSSH
    
    
    
    
    
    • [x] [RFC on user experience](https://github.com/PowerShell/PowerShell-RFC/blob/master/4-Experimental-Accepted/RFC0010-SSH-Remoting-Cmdlets.md) closed
    
    
    
    • [x] Implemented in PowerShell Core 6.0
    
    
    
    • [ ] SSH remoting slower than WSMan remoting #2852
    
    
    
    • [x] PSRP over SSH from Linux to Windows fails after password #2473
    
    
    
    • [ ] Enter-PSHostProcess while in a PSRP/SSH session #2453
    
    
    
    • [ ] Fix Ctrl+Break hang #2323
    
    
    
    • [x] Fix Ctrl+C #2321
    
    
    
  
  
  • [ ] WinRM client (New/Enter-PSSession, Invoke-Command -Session) on macOS/Linux
    
    
    
    
    
    • [x] Basic auth works on macOS (TODO: done?)
    
    
    
    • [x] Basic auth works on Linux
    
    
    
    • [ ] NTLM auth works on macOS
    
    
    
    • [x] NTLM auth works on Linux
    
    
    
    • [x] TODO: generate more demos/tasks here
    
    
    
  
  
  • [x] Misc. *-PSSession*
    
    
    
    
    
    • [x] Implicit remoting between PS Core and Windows PS #2592
    
    
    
    • [x] Fix Register-PSSessionConfiguration error #2555
    
    
    
  
  
• [ ] Existing cmdlet coverage ported
  
  
  
  • [ ] TODO: list? Start from this
  
  
• [x] Telemetry
  
  
  
  • [x] Close on this RFC on implementing basic census telemetry
  
  
  • [x] Implement telemetry
  
  
• [x] Progress bar
  
  
  
  • [x] Progress bar can significantly impact cmdlet performance #2138
  
  
  • [x] Write-Progress bar does not go away after operation is finished #1625
  
  

Documentation

• [x] Stand up 6.0 reference docset on PowerShell-Docs
• [x] Figure out story/location for conceptual x-plat content
• [x] Create a changelog workflow
• [x] SDK docs via docfx TODO

Packaging, Installation, and Deployment

• [ ] Install-Package PowerShell
  
  
  
  • [ ] Windows
  
  
  • [ ] Nano
  
  
  • [ ] Linux?
  
  
  • [ ] macOS?
  
  
• [ ] Update-Package PowerShell?
• [x] Universal Windows packages for each bitness #2608
• [x] Onboard to Microsoft Linux package repositories #3056
  
  
  
  • [x] RPM
  
  
  • [x] DEB
  
  
• [ ] Get into major package repositories
  
  
  
  • [ ] Ubuntu
  
  
  • [ ] Red Hat
  
  
  • [ ] TODO: who else? SLES?
  
  
• [ ] Fully automate package building for all platforms

Script/Module Development Experience

• [x] VS Code features
• [x] .NET Standard 2.0 story
  
  
  
  • [x] I can write binary modules that target Windows PowerShell and PowerShell Core
  
  
  • [x] Timeline public for .NET Standard 2.0
  
  
  • [x] Move to .NET Core vNext that supports .NET Standard 2.0
  
  
  • [x] Validate that .NET Standard 2.0 supplants the need for a Windows Powershell 6.0 (i.e. based on the FullCLR .NET Framework)
    
    
    
    
    
    • [x] Does .NET Framework 4.6.1 work on Windows 7?
    
    
    
  
  
  • [x] Move to csproj build? #3140
  
  
• [ ] Semantic versioning #2983
  
  
  
  • [x] PSVersionTable/PSEdition story
  
  
  • [ ] Transformation parameter attribute to convert semantic version to parameter
  
  
  • [ ] TODO: spec needed
  
  
  • [ ] Invoke-Command -Session $s -Command {$PSVerionTable} Fails Due to SemanticVersion #1819
  
  
• [ ] Artifact Sharing
  
  
  
  • [ ] Gallery supports filtration by platform
  
  
  • [ ] PowerShellGet supports filtration by platform
  
  
  • [ ] Gallery supports filtration by Windows PowerShell vs. PowerShell Core
  
  
  • [ ] PowerShellGet supports filtration by Windows PowerShell vs. PowerShell Core
  
  
• [ ] ScriptAnalyzer rules
  
  
  
  • [ ] Enumerate rules for supported features/cmdlets on Linux
  
  
  • [ ] Enumerate rules for supported features/cmdlets on .NET Core
    
    
    
    
    
    • [ ] Analysis based on using assembly, Add-Type, etc.
    
    
    
  
  

Scenarios

• [x] I can use PowerShell on major Linux distros, macOS and Windows
• [x] I can know how many people are using PowerShell (incl. version and platform) and how the Community is growing​
• [ ] I can use PowerShell on any platform to manage Azure
• [x] I can develop cmdlets for both Windows PowerShell and PowerShell Core using .NET Standard 2.0
• [ ] I can remote between all OS platforms using any supported remoting protocol (PSRP over SSH or WSMan)
• [x] I can install/upgrade PowerShell using native package management utilities on any Mac/Linux platform
• [x] I can use semantic versioning for modules with PowerShellGet and the Gallery​
• [x] I can develop a CLI experience using PowerShell on any platform to manage cloud instances
• [x] Finish top UserVoice delighters (SemVer, Build verb, Get-Service improvements, loose manifest validation)​

[Jaykul]

I can write binary modules that target Windows PowerShell and PowerShell Core

This works already -- targeting .NET Standard 1.6. The hard part is loading OS-specific assemblies -- do we need /lib/{OS}/*.dll automatic loading of RequiredAssemblies?

[pcgeek86]

WinRM client with Kerberos and client certificate authentication, from Linux and Mac OS X is something I'd consider essential. We're looking for the ability to deploy remote PowerShell code to Windows systems from non-Windows systems, via Docker containers.

Would NTLM cover this scenario in a secure manner? I'm not clear on the pros / cons of NTLM vs. Kerberos, but either way, I think client certificate authentication would be a separate topic.

LMK

Cheers,
Trevor Sullivan

[fabiendibot]

I totally agree what @pcgeek86 is saying, targetting WinRM from Linux is a totally unfriendly scenario and NTLM isn't possible with many customers.
There is a community YAML module but could it be possible to integrate YAML cmdlets the same ways as ConvertTo/ConvertFrom-* exists already for CSV/XML/JSON ?

[joeyaiello]

@pcgeek86 @fabiendibot good to hear. I then pose the question: are you okay AD-joining your Linux (or Mac) boxes? Or do you expect to be manually handling the certs?

Better yet, what's the blocker for you using PSRP over SSH from Mac/Linux to Windows? Do you have some sort of cert solution that's simpler than public/private key pairs?

[pcgeek86]

We've got a separate certificate publishing system in place already, so that's taken care of.

I'll have to see how PowerShell Remoting over SSH works before I can comment further on that scenario. As of this point, I'm not aware of any functional implementation of it. The solution would need to work on down-level Windows operating systems though.

[pcgeek86]

I'd also add some emphasis around building binary modules surrounding .NET Standard. I'm glad to see this was added in there. Perhaps we should add something around loading .NET assemblies into PowerShell, and calling into them? I know a lot has changed in .NET Core, with respect to AppDomains, reflection, and so on ... I think this area could use some attention.

[whatevergeek]

i agree to both @Jaykul and @pcgeek86
a powershell gac or library folder sort of would be good...
this will help us manage assemblies that our corresponding modules are using/installing...
i think node/python also have this concept...

[fabiendibot]

@joeyaiello We configure kerberos with our Linux boxes for some scenarios (SQL Server connections mostly). For me Win32-SSH is not production ready so i haven't looked at it for now.

[iSazonov]

Does .NET Framework 4.6.1 work on Windows 7?

Yes
https://www.microsoft.com/en-us/download/details.aspx?id=49981&e6b34bbe-475b-1abd-2c51-b5034bcdd6d2=True

Supported Operating Systems:
•Windows 7 SP1 (x86 and x64)
•Windows 8 (x86 and x64)
•Windows 8.1 (x86 and x64)
•Windows 10
•Windows Server 2008 R2 SP1 (x64)
•Windows Server 2012 (x64)
•Windows Server 2012 R2 (x64)

[fMichaleczek]

What's about the Class Features ?
Interface implementation is still missing.

This was the roadmap at the end of 2014 :

PowerShell need to be SOLID at 6.0 (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) )

Language area need more attention, particularly these issues :
https://github.com/PowerShell/PowerShell/issues/2223
https://github.com/PowerShell/PowerShell/issues/2642
https://github.com/PowerShell/PowerShell/issues/2225
https://github.com/PowerShell/PowerShell/issues/2217

Thank you !

[iSazonov]

Perhaps it would be useful to draw up this roadmap by using the GitHub Project(s).

[ghost]

Having interfaces would be cool!

[SteveL-MSFT]

@iSazonov we considered using GitHub Projects, but decided (for now) it would be easier to track progress as checkboxes in an issue

At this time, our thinking is to invest in the developer experience (class improvements as well as things like bindings to other languages, authoring cmdlets in other languages, etc...) post 6.0 rather than continuing to add features into 6.0.

[ghost]

Well, right now the developer experience is not so good! ISE is a joke without ISESteroids, and VS CODE is buggy as hell. This is leaving us with PowerShell Studio as the only option, but intellisense there is close to none.
So, maybe the right thing to do would be to invest in developing a good IDE, with PS 5-6 features support.

[SteveL-MSFT]

@g8tguy our plan is to invest in VS Code specifically via PowerShellEditorServices as it's open source and cross-platform. If there are any specific issues or capabilities that prevent you from using VS Code, please open issues in that repo.

[daviwil]

@g8tguy if VS Code is "buggy as hell", file issues so I can fix them :)

https://github.com/PowerShell/vscode-powershell

[ghost]

The Last time I tried VS Code, was like half a year ago.
And the language server was constantly crashing when you
open 5-10 tabs with custom PS 5 classes and enums referencing one another, so IntelliSense stopped working, and the IDE was behaving kind of weird. I wanted to port, PowerShellEditorServices To IDEA, but it seemed too much work for one person, so I stuck with PS Studio. But as I'm viewing the PowerShellEditorServices changelog now, it certainly seems that lot's of the bugs were resolved, and VS Code become more mature and stable, so I'll give it another shot. And Thank you guys for the product, you are doing a great job, advocating PowerShell! 👍 :1st_place_medal:

[daviwil]

@g8tguy yep, a lot has changed since then. If you still run into issues developing scripts with classes in VS Code I'd be happy to try and fix them. Making Editor Services work in IDEA should certainly be achievable, if you ever try again I'd be happy to give you some pointers.

[iSazonov]

I can confirm - latest PS Code's versions is good! It happened in the last couple of months. Many thanks to PS Code developers!

[ghost]

How about support for long paths / file names? As .NET Core now supports them, I know there's been hope of this coming to PowerShell eventually - https://github.com/dotnet/corefx/issues/645. I'm sure that there will be much rejoicing in the enterprise world if/when this happens.

[SteveL-MSFT]

@itpaul PowerShell Core already supports long paths by default :)

[ghost]

@SteveL-MSFT Sweet! Thanks for sharing. Any idea on when this could make it's way into non-Core PS?

[SteveL-MSFT]

@itpaul PowerShell v5.1 on Win10 already supports it, but not be default (since the OS doesn't support it by default, if Win10 ever changes that setting, it'll just work automagically). You can enable it following this: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

[ghost]

@SteveL-MSFT Fantastic! Thanks again for your help. I'll start looking into it. After your first reply I discovered that you can run PowerShell Core portably, which is also fantastic! It appears that I'll be able to avoid implementing Alpha FS into our environment now.

[SteveL-MSFT]

@itpaul one of the decisions we wanted to go with CoreCLR besides the cross platform support is that it inherently supports side-by-side, so you can "install" (which is really an xcopy) of PSCore6.0 and it'll run happily next to Windows PowerShell v5.x without impacting existing scripts/apps that depend on v5.x

[ghost]

@SteveL-MSFT Pigs truly can fly in the Nadella Microsoft world. Christmas has definitely come early this year.

[iSazonov]

1. Seems we have issues with the conhost referred in some issues. This is not only a progress bar.
2. For progress bar performance #2822 is opened.
3. It would be good to have code analysis for performance (security, quality, formatting).
4. We could get a great feedback from Windows 10 Preview if integrated in this program. (In WSL too)
5. The plan does not mention WSL (Windows Subsystem for Linux). This could be a great platform for testing and promotion of Powershell Core. Now we have issues with WSL.

[ChristophB125]

Great work! Are you planning to support Docker as well (we are planning to ship PowerShell Core modules)? Could you also upload the notes or recording of the 2nd RFC please as you did for the first one?

[SteveL-MSFT]

@HemantMahawar is the recording ready to be uploaded from the last Community Call?

[joeyaiello]

@iSazonov: Could you link me to some of those conhost issues? The two I have above, #2138 and #1625 look like progress problems to me. (In my mind, even if they're caused by the underlying console hosts, we have so little control over the underlying hosts across platforms that progress functionality is what needs to be refactored or even limited). Also, added #2822. 👍

I agree with you on code analysis. Maybe @JamesWTruher or @SteveL-MSFT could spin up an Issue for me to add here?

I hear you on WSL support, but I think we're prioritizing Linux distros and macOS right now because of the lack of compelling scenarios for using PowerShell from WSL. Furthermore, I think they eventually (this is only from public knowledge with zero internal knowledge of timelines or how the functionality might work) plan on interoperating with Windows processes, in which case you wouldn't need to run "PowerShell on Linux" from within WSL but just "PowerShell Core 6.0 on Windows".

If you disagree with my statement on "compelling scenarios", please let me know. I love to be proven wrong on these sorts of things :)

@ChristophB125: could you elaborate more on what you mean by "support Docker"? We currently have Docker listed as a platform, and we publish a ton of images to the Docker Hub (including nightlies, though it looks like we forgot to publish alpha.15, I'm following up).

If you mean, do we have a PowerShell module for managing Docker, the Hyper-V team has already done exactly that. It already supports Windows PowerShell 5.x as well as PowerShell Core 6.0 on Windows, Nano, macOS, and Linux.

Out of curiosity, who is "we"? Would love to talk more about how you're using PowerShell 6.0 :)

[joeyaiello]

Also, I got some bad news. It looks like checkboxes do NOT automatically get checked when issues get closed (at least not at the L3 level). I closed #2245 and it didn't get checked by itself (and that's one where the entire line is just the issue number....) 👎

[SteveL-MSFT]

@joeyaiello submit feature request to GitHub 😸

[HemantMahawar]

@ChristophB125 Recording of the 2nd community call is now available on PowerShell & DSC Team Channel /cc: @SteveL-MSFT & @joeyaiello

[iSazonov]

@joeyaiello

Could you link me to some of those conhost issues?

Oh, it is hard to do but it seems I've gathered main together (I believe there are other useful comments that we have missed.)

If you disagree with my statement on "compelling scenarios", please let me know. I love to be proven wrong on these sorts of things :)

I agree but there are still "compelling scenarios".
Microsoft announce WSL as "kill" developer feature:

The WSL was designed and built by the Windows Kernel Team and delivered in partnership with Canonical, to help Windows 10 developers use the rich Linux developer ecosystem and tools alongside the great tools they are already using in Windows, without having to boot into another operating system or VM. This is definitely a “by developers, for developers” Windows 10 feature, specifically designed to remove a bit of friction from developers’ daily workflow.

As a Windows user I tried to use the Powershell Core under WSL and failed 😕
I want:

1. Develop and test powershell scripts
2. Develop and test binary powershell modules
3. Build Powershell Core from sources
4. Develop and debug features of Powershell Core

I believe that this is fully in line with the Microsoft WSL announcement.
It would be great to ask Kernel team to help us to get it working.

[ChristophB125]

@joeyaiello Thank you for the answer. Yes, the PowerShell docker images is what I was looking for. This would be great because then PowerShell can get shipped as part of the deployment (we have the fear that our clients are anxious about Microsoft's IP being on their Linux machines therefore docker can help us hide that at least at install time). By the way,, 'we' is just loosely referring to the team in my company that I work for, which I cannot disclose here. Although we are a Microsoft Gold partner the information from the dev team directly is very valuable to us. As GitHub does not allow private messaging any more, I sent you a LinkedIn request instead if you want to find out a bit more about how we use PowerShell.

@HemantMahawar Thanks for the effort. I am looking forward to join the next call!

[lzybkr]

@iSazonov - the WSL issue affecting you the most is probably https://github.com/dotnet/corefx/issues/12452 - so it doesn't require a fix in Windows - anyone could jump in to fix it (though it sounds like it might not be a simple fix or it'd be fixed already.)

[lzybkr]

And after reading an update to the issue, maybe a fix is coming from WSL. We'll see.

[iSazonov]

@lzybkr Thanks! Build 15025 still has the bug. Waiting next build.

[iSazonov]

@joeyaiello #2882 move to dotnet-resgen (support compile "file.En-Us.resx") and csproj.

[joeyaiello]

@iSazonov: You're saying those are two separate items, right? The former is a requirement for localization (something we need to discuss with @PowerShell/powershell-committee, I'm not sure how we get that done today), and the latter is a requirement for moving to .NET Core 2.0 (a requirement for supporting .NET Standard 2.0).

[SteveL-MSFT]

@joeyaiello we have a custom solution for res-gen today, but we should move to the dotnet supported way. csproj is moving to msbuild, although we've talked about it, I don't see an issue for it.

[iSazonov]

@joeyaiello Steve said more clearly than I. We already have the issue for dotnet resgen and we should open a issue for csproj. And we should include the issues in the Plan under "dotnet 2.0"

[joeyaiello]

Added the csproj/MSBuild goodness, we still should talk about resgen and whether it's required for 6.0.

[KirkMunro]

This might be more Hyper-V than PowerShell (or equal parts Hyper-V and PowerShell), but I thought I'd mention it to make sure: I think it's very important to have PowerShell Direct work for Linux VMs as well as Windows VMs.

[pcgeek86]

@SteveL-MSFT Thank you for focusing on developer experience as a priority over adding new features. I strongly agree with your direction. Start by creating a solid foundation, and add features post-6.0. /cc @joeyaiello

[iSazonov]

AppImage #2024 in Packaging, Installation, and Deployment

[iSazonov]

@joeyaiello #2138 and #1625 fixed - I put marks in Plan.

[mnaiman]

I think NTLM auth over SSH should be included in release same as for WinRM

[iSazonov]

@joeyaiello #3140 fixed - I put the mark in Plan.

[joeyaiello]

@mnaiman I'm...actually not sure if that request makes sense from a crypto perspective. I challenge you to try what it is you're trying to do and report back if it doesn't work. We support password-auth for domain and non-domain accounts in SSH-based remoting (both with and without PSRP). I'm not sure that it goes through any kind of NTLM layer (as I'm not sure SSH support NTLM), but I don't think it should matter from a functional perspective.

EDIT: Maybe @manojampalam can comment here.

[SteveL-MSFT]

@mnaiman @joeyaiello currently, we don't support SSO as SSH itself by default prefers keyboard-interactive auth which works just fine with NTLM and Kerberos against Win32-OpenSSH. So this is different from WinRM remoting, but is consistent with SSH.

[mnaiman]

@joeyaiello @SteveL-MSFT SSH SSO provider is "gssapi-with-mic" (NTLM & Kerberos).

It allows single sign on on windows without typing password or saving private key somewhere.
Some part of gssapi is already here https://github.com/SimonWilkinson/gss-openssh/
Here implementation for client https://github.com/Lax/net-ssh-kerberos
Free/Commercial servers which supports gssapi PowershellServer & Bitwise SSH.

Here is already request in https://github.com/PowerShell/Win32-OpenSSH/issues/96

[pradeepprakhar]

I am running powershell on MAC machine.

$psversiontable
Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   3.0.0.0
GitCommitId                    v6.0.0-alpha.13
CLRVersion
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

But send-mailmessage command is not working for me. I am getting below messages.

send-mailmessage
send-mailmessage : The term 'send-mailmessage' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path
was included, verify that the path is correct and try again.
At line:1 char:1
+ send-mailmessage
+ ~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (send-mailmessage:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

[jsburckhardt]

I'm having an issue with PS 5.0 when running invoke-webrequest... basically if the response comes with quotes in the utf-8 value it will fail. Will this be fixed in the GA version (https://stackoverflow.com/questions/36275618/why-is-invoke-webrequest-and-invoke-restmethod-failing-and-succeeding-at-the-sam)

[iSazonov]

@pradeepprakhar Now 'send-mailmessage' is ported.

@jsburckhardt Please open new Issue with full description your problem or question.

[iSazonov]

@joeyaiello #929 and #2227 was fixed.

[SteveL-MSFT]

Did some updates to the list above on what is closed/completed and what was cut out of 6.0.0 and will likely land in 6.1.0 instead

[erichiller]

Are there plans to add comment support (or at least ignore them) in the list for ConvertFrom-Json?

[SteveL-MSFT]

@erichiller please open a new issue, we can consider for 6.1.0

[VGerris]

Just include Kerberos support please (and WinRM perhaps too) then we look at this again.

[SteveL-MSFT]

@VGerris if by WinRM you mean WSMan, that support is already included. There is experimental Kerberos support for WSMan on non-Windows, although it's overly complex currently to get it working.

[VGerris]

No I mean Kerberos and WinRM just like I wrote. Please focus on getting that supported, so one doesn't have to rely on third party scripts. What we basically want is a way to efficiently monitor a Windows machine via an agentless solution and to be able to run remote commands in a secure manner. It's clear from the thread this is a main feature on the rank of interests, right? Thank you.

[SteveL-MSFT]

@VGerris I don't understand what you mean by WinRM then since that is supported on Windows (and works already with PSCore6) and WinRM is a Windows-only feature (Windows Remote Management). WSMan is the protocol that WinRM implements.

[bergmeister]

The following architecture diagram from here might help to understand WinRm-WSMan:

[joeyaiello]

I understand a little better why this diagram is drawn the way it is when I looked at the blog for it, but it's a little misleading. Basic way to think about it is that WSMan is the protocol/standard (short for WS-Management) and WinRM is the implementation of that protocol as a service in Windows.

@VGerris as @SteveL-MSFT said, what you're talking about can technically work, but it's extremely difficult to configure and it requires that your Linux machine is AD domain-joined (which is also difficult to pull off). For those reasons, we don't currently formally support that scenario.

However, WSMan based remoting is not agentless. You still have to run the WinRM service on your Windows machine: that's an agent. In the next release of Windows 10 and Windows Server, OpenSSH itself will be available as a supported feature-on-demand, so you'll have first-party, inbox support for SSH-based remoting as a peer to WSMan-based remoting.

[joeyaiello]

I'm also closing this issue due to it having outlived it's usefulness. We should continue tracking this work in the issues that have been created. If you're passionate about something here that doesn't have an issue, please open one so we can track it there.

I also plan on fixing up Projects at some point, I know that's in somewhat of a busted state right now. Sorry about that, folks....