new-pssession -ConnectionUri is not supported in the client options about psl-omi-provider HOT 18 CLOSED

Redirection has now been checked in.

@vinodc question: To access office365, do you need any specific proxy settings or proxy authentication? We don't have that today. For us at Microsoft they have automatic socket forwarding so we don't need special configuration, but I can believe some folks may need this.

Also, although this feature is basically complete at this point (or will be when the binaries are dropped to PowerShell in a week or two after we have a proper test pass), the performance associated with connecting to Office 365 from PowerShell on Linux/OSX is pretty terrible. The fix that is most likely going to help this is microsoft/omi#217, although #35 may affect it too.

from psl-omi-provider.

seems we may be in luck. Our changes have been submitted to PowerShell and so will be in the next release of powershell. It seems the Friday release slipped so this change should get into that release now.

from psl-omi-provider.

@vinodc yes. The whole connection string parsing was actually not completed. My bad. I only parsed machine/wsman-prefix. I have added the rest.
Not sure if this fix and the fix needed in microsoft/omi#184 will make it into the next powershell package at this point, but I will try.

from psl-omi-provider.

sorry, still running through our testing. still hoping for end of month.

from psl-omi-provider.

powershells use of connectionuri means http://computername goes to port 80 instead of default wsman port. Will need to be overridden with http://computername:port

from psl-omi-provider.

Note that this issue was created regarding connecting to office service with a live ID account. There is an issue in OMI that causes user@domain to not authenticate properly and it strips off the domain. That is tracked in OMI issue microsoft/omi#184

from psl-omi-provider.

@paulcallen Not sure if this is relevant, but I also noticed that the DNS queries powershell made when I used the connection URI was to obtain the IP of "http:." rather than for "computer.domain.com." like I would expect. Observed this via tcpdump. I'm assuming this is due to splitting on '/' incorrectly?

Edit: I see the commit adds in support for identifying the "http://" and "https://" prefixes, which would likely resolve the symptom described above. Thanks for the super-quick change here!

from psl-omi-provider.

@vinodc, I am having problems validating everything to do with your original scenario that you were testing. I pulled in this fix along with the other underlying basic auth test (which has not been commited to master yet) and I get access denied for my own personal account. I validated http url was used properly and the user/password was encoded properly, but still failed making it look like not anyone with an outlook account can carry out this request. Any thoughts?

from psl-omi-provider.

@paulcallen An Office 365 account would be required to connect to Office 365 PowerShell as an admin. If you like, I can share test credentials with you so you can verify the behavior, if you could share your email address with me either here or via email at vinod [at] kloudless.com

from psl-omi-provider.

@vinodc Sounds like it should work for me then, but it is not. My alias is paul.c.allen [at] Microsoft.com.

from psl-omi-provider.

thanks @vinodc. Seems like we also have issue #71 that needs to be resolved before this whole scenario works. I have also created issue #72 to implement http redirection.

from psl-omi-provider.

Got it! #72 can most likely be worked around for the current time by resolving the URL prior to performing the request.

from psl-omi-provider.

@paulcallen Great to hear! No proxy settings should be needed to access Office 365. We've also noticed poor performance via Windows, but I agree with your analysis that compression/caching may help.

from psl-omi-provider.

Closing issue as associated fixes are checked in. Our hope if to drop PSRP/OMI bits into PowerShell by end of February.

from psl-omi-provider.

Did this happen to make it into the alpha.16 build that just dropped? Or will this be in a later PowerShell build?

from psl-omi-provider.

@paulcallen Checking in to see if there was an updated timeline for the next build. Any idea around when it would be available?

from psl-omi-provider.

Discovered a couple of build/upgrade issues that we finally think are fixed. Will be hopefully throwing final builds at our test team tonight, although I still have a few final validations I need to do myself before that. Goal is to pass bits off to PowerShell at the end of the week. @SteveL-MSFT may be able to give more details as to when the next PowerShell build is likely to be after that.

from psl-omi-provider.

@paulcallen the next release after alpha.17 (which is planned for today) is approx. two weeks. Individuals can always pick up nightly builds to test.

from psl-omi-provider.