Powershell Studio - Running App As Another User - Win 8.1

[pdearmen]

An odd issue that currently only is seen by a small subset of my users at work but as windows 8 rolls out more I assume I will see this more.

I wrote some code in Powershell Studio 2012 (latest version as of 3/25/2014). When I packaged the code into an exe it shows an odd behavior in windows 8.1 where the minimize,maxamize,and close buttons don't appear correctly.

If I package the same exe to run under the current user context it works fine.

I just assumed this was a powershell studio 2012 issue since 2014 was out and hoped it would work correctly in the 8.1 environment.

Thankfully new projects do work correctly in 8.1 - the close,minimize,maxamize buttons show when executed as another user. (happy about this )

The only issue is that all of the scripts/forms i wrote in the old 2012 environment still show this same behavior. I can load the 2012 file in 2014 and allow it to go through its conversion. After the conversion ends I package it in 2014 and still show the same results.

Is there a way to correct this? I would prefer not to have to write all my forms/code from scratch as there is a significant project we have written using powershell studio which is 100k+ lines of custom code for our operations department.(as well as close to twenty different forms)

I have attached screenshots of running in my user context as well as another username (one which has full admin access to my machine and a profile as well)

Machine: Windows 8.1 x64 fully patched
Powershell Studio: x64 V 4.1.57

Anyone else run into this or thoughts on how to correct?

[davidc]

Sorry I missed this post.

Since this is a packaged executable, it is possible the manifest contained in 2014 packaged executables makes the difference to Windows 8.1. Are you using a custom manifest?

As for the script itself, the code we generate does not control the rendering of the outer window and there isn't much different between 2012 and 2014 within that regard. I recommend doing a comparison between the exported scripts.

The only thing the generated script does do is make a call to [System.Windows.Forms.Application]::EnableVisualStyles() which tells windows to use the OS theme when rendering the controls. In the second screenshot it looks like it is rending the windows using the vanilla windows theme instead of the Windows 8 theme. Not sure why the OS is ignoring the call. This smells like a Windows 8.1 bug, since this hasn't occurred on the other OS versions.

David

[pdearmen]

I have the embed default manifest option selected when i package the file.

I'm not sure how to do an export of the code as another user??? Maybe i'm just having a blond moment.

But what I did do was packaged the code to run as an elevated user account I have and ran it and was able to see the same issue. I then took the exported code and manually ran it under a powershell session in that same elevated account. It ran perfectly - so the code itself is working fine.

For fun, I took one of my simpler forms which had this issue and copied all the elements into the new form created under 2014 and when i packaged it, it worked perfectly as another user.

I guess im a little confused now. Considering the only difference is the base form and the username it runs under.

[davidc]

I will bring this up with the dev team, but as I mentioned this is probably a Windows 8.1 issue. In addition, it seems like a cosmetic issue only is that correct?.


Are you supplying the alternate credentials use the Packager's settings or are you simply running the packager exe under another user account?

David

[pdearmen]

It is a cosmetic issue - and only seems to be confusing my users - so not a detrimental thing but I don't want to have to rebuild our large toolset to avoid that confusion if I can avoid it

Im using the packager and setting the options under Alternate Credentials to:

RunMode: RunAsUser
and then setting the username and password