jockebr Nov 4, 2013 at 8:05 AM Edited Nov 4, 2013 at 8:07 AM In SCCM 2012 there is a limitation when you use the new Application model. The option "Allow the user to view and interact with the program installation" can only be selected if you also select the logon requirement to run "Only when a user is logged on". If you however instead use the old Package/Program model you can make it run whether or not a user is logged on and still allow the user to interact with the program installation. The option to allow the user to interact with the program is vital when using PS App Deployment Toolkit, because otherwise the dialogs (i.e. when you inform the user that a certain application must be closed for the installation to proceed) will not show. But obviously, we also want the installation to be able to run when no user is logged on to the computer. So we are forced to chose. Either we use the old Package/program model, which most of us that use SCCM prefer to avoid. Or we use the Application model but only allow the installation to run when a user is logged on. None of these two alternatives are really good, and this dilemma has been discussed on this site before. This weekend I did some research to this problem to find a solution. What I want is to use an Application, be able to run it whether or not a user is logged on, and still be able to show the dialogs. Period. I explored and tested different solutions and I have found a way to finally work around this stupid limitation. It is possible to let a process that runs in Session 0 create another process with a logged on user's credentials in another session. Basically what you do is look at the winlogon.exe process to find what session the logged on user belongs to and then use the CreateProcessAsUser function to create the new process in that session. There are plenty of blogs, articles and code examples out there how to accomplish this. I am not a professional developer myself, so I'm not really up for the challenge. What I'm hoping for is that the PS App Deployment toolkit developers will implement this in a future release to the Deploy-Application.exe file, so that it can start the Deploy-Application.ps1 script in another session. I will be happy to help with all the information I have found on how to do this, and provide all the links to useful resources I have on this matter. Until then I will be using a third party application to launch the PS App Deployment toolkit in the user session. I have found two that works great. First the psexec utility from the pstools: http://technet.microsoft.com/en-us/sysinternals/bb896649.aspx But the one I will be using is ServiceUI.exe from the Microsoft Deployment Toolkit. This little executable is created for the sole purpose of breaking out of the Session 0 isolation and display a UI from Session 0 to a user session. It is very lightweight (only 70 Kb) and works like a charm. So the solution is: Download MDT 2013 from Microsoft and install it. Get the ServiceUI.exe from the MDT installation folder. Get the 32-bit version from the x86-folder so you can use it on both 32-bit and 64-bit systems. Add the ServiceUI.exe to each application source folder that you will be deploying with the PS App Deployment Toolkit. Use this command line as your installation program in your applications: "ServiceUI.exe Deploy-Application.exe". Make sure you also tick the checkbox "Run the installation and uninstall program as 32-bit process on 64-bit clients". Configure the User Experience settings with the following options: Install for System Whether or not a user is logged on Normal Doing this and you will be able use Applications instead of Packages to run the installation whether or not a user is logged on and still display all dialogs. I hope this solution can help someone that has been struggling with this issue. And in the long run I hope PS App Deployment Toolkit team will implement the necessary code in the toolkit, so that we don't need to use the ServiceUI.exe. Like I said earlier, I would be happy to help in any way I can. sintaxasn Nov 4, 2013 at 12:56 PM Hey Jocke, We did extensive investigation into this before and trying to code up our own solution was a bit of a nightmare. As I'm sure you saw in the blog posts, there's a lot of trickery involving security tokens and user impersonation. Additionally, most of the code written to do this sort of stuff is written in C and you need to be fairly knowledgeable in Windows development to know what's actually going on - we have concerns that we could introduce bugs and not have any idea how to fix them. For that reason, we're inclined to look at ServiceUI.exe more closely and see if we can integrate it better. I have something I'd like you to test. Can you drop me a message and I'll send you something to check out? Thanks, Dan sintaxasn Nov 6, 2013 at 3:49 PM Hey, Ok so I've pushed our preliminary 3.1.0 branch to here: https://psappdeploytoolkit.codeplex.com/SourceControl/latest Can you download and test please? Want to make sure we haven't broken anything else. Note, this is not the final 3.1.0, as we still have a few more changes and fixes to go in here, but it would be great if we could get help testing the new functionality, and making sure we don't cause issues elsewhere. Thanks, Dan jpm2686 Nov 7, 2013 at 3:56 PM I'm interested in migrating existing scripts to the 3.1.0 and later releases to test how it handles the hidden behavior of Session 0. What is the process to integrate the 3.1.0 changes into the work I've already done with the 3.0.6 release? Basically how do I go about 'upgrading'? I'm guessing I just replace everything, then update the 3.1.0 'Deploy-Application.ps1' with any customization I've done to the 3.0.6 'Deploy-Application.ps1'. Does this sound correct or is there a simpler method? Thanks for all the work you've put into this project - I wish to integrate this into all my SCCM applications. sintaxasn Nov 7, 2013 at 4:02 PM Just replace the AppDeployToolkit folder. There has been no substantial changes to Deploy-Application.ps1 since 3.0 - you will need to replace the Deploy-Application.exe though as this is how we drive the Session 0 switch. jpm2686 Nov 7, 2013 at 10:53 PM Edited Nov 7, 2013 at 10:53 PM Is there any need for ServiceUI.exe and should I force the installation to run as a 32-bit process on 64-bit clients? sintaxasn Nov 7, 2013 at 10:54 PM Nope, all taken care of in the Deploy-Application.exe :) jpm2686 Nov 8, 2013 at 6:05 AM Edited Nov 8, 2013 at 6:06 AM It seems I still most often have the same behavior even after updating Deploy-Application.exe and the AppDeployToolkit folder to v.3.10. The process is running but noninteractive in Session 0. When it does prompt in Session 1 (not sure what is happening differently) install will finish then I see this afterwards - I don't think it's thrown by my application. Could this be some bug in the new logging enhancements? If I can help by providing logs let me know what you need. Thanks. sintaxasn Nov 8, 2013 at 4:21 PM The dialog was a glitch, something I forgot to remove. Woops :) I've added new logging for Deploy-Application.exe. Can you pull the latest source, try again and if you have an issue with it not showing up in the correct session, post the log from here: C:\Windows\Temp\AppDeployToolkitStartup.Log Thanks, Dan sintaxasn Nov 8, 2013 at 4:23 PM Also, I see from the screenshot that you're running Deploy-Application.exe with parameters, but I dont know what ones or how you're calling them. It's possible that this may be interfering somehow. Can you post them too? Cheers again, Dan jpm2686 Nov 9, 2013 at 4:18 AM Dan, I'm using the latest revision of 3.1.0 - SCCM Software Center status = 'Installing' but it appears to be hung. Deploy-Application.EXE is running is Session 0 so I see no UI. Here is contents of AppDeployToolkitStartup.Log and screenshot which includes parameters requested: Running under SYSTEM context: True Running under Session 0: True ServiceUI: x64 ======================= Logon Lookup ======================= [winlogon.exe] Session: [1] PID [480] [Target Session [1] = Match] ======================= Launch Process ======================= Program to launch : [C:\WINDOWS\System32\WindowsPowerShell\v1.0\PowerShell.exe] Command line : [C:\WINDOWS\System32\WindowsPowerShell\v1.0\PowerShell.exe -ExecutionPolicy Bypass -NoProfile -File C:\Windows\ccmcache\6u\Deploy-Application.ps1 -DeploymentType Install] API [CreateProcessAsUser] Error: [5] ======================= Exiting with [-1] ======================= Failed. Falling back on standard launch method jockebr Nov 10, 2013 at 3:55 PM Ok, I have FINALLY found some time to test the newest release. And it WORKS! :) Great job!!! Two issues that I have found: I still have to run the installation program as a 32-bit process, or it won't work. This is a not a big deal if it should prove difficult to fix, but my guess is this is a simple bug. Maybe a typo somewhere so it's trying to launch ServiceUI.exe instead of ServiceUI64.exe? The Powershell window is visible and flashes by the screen for a second when the installation is started. This is not a big deal either, but if it can be removed then great. Once again - Great job!!! Cheers, Jocke sintaxasn Nov 11, 2013 at 2:11 PM I've made some changes which will hopefully resolve the issue and no longer require 32-bit process being checked. I've also tried my best to hide the PowerShell window but it's definitely going to flash up for a second - it won't show any detail any more though. Dan doum Nov 12, 2013 at 9:22 AM Hi, I'm currently testing the 3.1.0 beta, which resolve some of my previous questions in another thread ;) But I have a problem with welcome screen for closing application. I use this command line : Show-InstallationWelcome -AllowDeferCloseApps "firefox=Mozilla Firefox" -AllowDefer -DeferTimes 3 -CheckDiskSpace -PersistPrompt -BlockExecution  but if I launch firefox, then I refresh deployment, installation is starting and it closes firefox application without asking me nothing. (I want to show welcome screen only if Firefox is running, if it is not, I just want to upgrade silently) Where is my mistake ? jockebr Nov 12, 2013 at 2:16 PM doum, try and run the installation as a 32-bit process and see if that helps. doum Nov 13, 2013 at 1:50 PM Before changing this, I just try on a Windows 7 32 bits computer and same thing, Firefox is closed without asking the user. doum Dec 13, 2013 at 1:24 PM Do you have an approximate release date for 3.1.0 ? sintaxasn Dec 13, 2013 at 4:20 PM Afraid we've put this functionality on the back burner - we can get it to reliably work in every environment. If you are looking for this ability, I would recommend following jockebr's guidance in the original post. Dan Jerre Dec 20, 2013 at 10:35 PM ok, I need to break out of session 0 to notify the user to close browsers if they are running. If I use the ServiceUI.exe method mentioned in the original post, will the installation run with system rights or does the logged on user have to be Administrator in order for my application(Java) to install successfully? That would be a dealbreaker i am afraid. Jerre Jan 7, 2014 at 8:12 AM Tested now, seems to work as I hoped, serviceUI.exe shows the PADT dialogs to the limited user and the uninstall/install of in my case Java completes with success. BTW, I use WSUS Package Publisher and PADT to upgrade Java, pretty nice set of tools for the money in my opinion! Lipid_Venom May 1, 2014 at 3:05 PM This work around has been working perfectly, however, I have been getting several odd error codes through SCCM and haven't been able to find a solution and though it may pertain to unique error codes used by this program? Deployment Failed - Error Code - 0x1388 (5000) Error Description - "Log off Network" AppEnforce.log shows the below info  Prepared working directory: C:\Windows\ccmcache\e1 AppEnforce 4/30/2014 2:00:05 PM 8672 (0x21E0) Prepared command line: "C:\Windows\ccmcache\e1\ServiceUI.exe" Deploy-Application.exe Install AppEnforce 4/30/2014 2:00:05 PM 8672 (0x21E0) Post install behavior is BasedOnExitCode AppEnforce 4/30/2014 2:00:05 PM 8672 (0x21E0) Waiting for process 7024 to finish. Timeout = 120 minutes. AppEnforce 4/30/2014 2:00:05 PM 8672 (0x21E0) Process 7024 terminated with exitcode: 5000 AppEnforce 4/30/2014 3:07:14 PM 8672 (0x21E0) Looking for exit code 5000 in exit codes table... AppEnforce 4/30/2014 3:07:14 PM 8672 (0x21E0) Unmatched exit code (5000) is considered an execution failure. AppEnforce 4/30/2014 3:07:14 PM 8672 (0x21E0) ++++++ App enforcement completed (4030 seconds) for App DT "Adobe Flash - Critical Update" [ScopeId_], Revision: 6, User SID: ] ++++++ AppEnforce 4/30/2014 3:07:14 PM 8672 (0x21E0)  Another Error I've gotten in large amounts in addition to the previous. Deployment Failed - Error Code - "0xFFFFFFFF (-1) Error Description - "Script execution failed with error code -1" (which I believe is user level issue?) AppEnforce.log shows the below info  Prepared working directory: C:\Windows\ccmcache\bf AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Prepared command line: "C:\Windows\ccmcache\bf\ServiceUI.exe" Deploy-Application.exe Install AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Executing Command line: "C:\Windows\ccmcache\bf\ServiceUI.exe" Deploy-Application.exe Install with system context AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Working directory C:\Windows\ccmcache\bf AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Post install behavior is BasedOnExitCode AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Waiting for process 5072 to finish. Timeout = 120 minutes. AppEnforce 4/30/2014 7:23:47 PM 912 (0x0390) Process 5072 terminated with exitcode: 4294967295 AppEnforce 4/30/2014 7:23:48 PM 912 (0x0390) Looking for exit code -1 in exit codes table... AppEnforce 4/30/2014 7:23:48 PM 912 (0x0390) Unmatched exit code (4294967295) is considered an execution failure. AppEnforce 4/30/2014 7:23:48 PM 912 (0x0390) ++++++ App enforcement completed (1 seconds) for App DT "Adobe Flash - Critical Update" [ScopeId_], Revision: 6, User SID: ] ++++++ AppEnforce 4/30/2014 7:23:48 PM 912 (0x0390)  Hopefully these are the only unknown errors I'll encounter, but other than this... ServiceUI.exe has been working great. Does it still install silently in no user is logged in? sintaxasn May 1, 2014 at 3:22 PM The first exit code 5000 is being passed back by the Toolkit - it means the user chose to Defer the install. The second however, I suspect is ServiceUI.exe itself. This is one of the reasons we never integrated ServiceUI completely - we saw some strange behaviour that frankly, we don't know how to fix since we didn't write ServiceUI or fully understand the trickery it's using the elevate. Does the deployment always fail on those machines or just once and works the next time? Hopefully it's intermittent and you can live with it when the retry happens. Oh! It's quite possible that if no user is logged on, ServiceUI is failing and returning -1. You could maybe solve this by having two deployment types, one for if a user is logged on, and one when not. Use ServiceUI if the user is logged on, and just use Deploy-Application.exe when no user is logged on. The toolkit will work in silent mode if no user is logged in. Hope this helps. Dan Lipid_Venom May 1, 2014 at 3:28 PM I JUST found an available machine that I could pull the toolkit log and you're correct about the 5000 being deferral code... I should have waited a bit longer for a machine to become available ;) [30-04-2014 15:07:14] [Pre-Installation] Setting deferral history...[DeferTimesRemaining = 0] [30-04-2014 15:07:14] [Pre-Installation] Creating Registry key [Registry::\HKEY_LOCAL_MACHINE\SOFTWARE\PSAppDeployToolkit\DeferHistory\Adobe_Flash_13,0,0,206_EN_01]... [30-04-2014 15:07:14] [Pre-Installation] Setting registry key [Registry::\HKEY_LOCAL_MACHINE\SOFTWARE\PSAppDeployToolkit\DeferHistory\Adobe_Flash_13,0,0,206_EN_01] [DeferTimesRemaining = 0]... [30-04-2014 15:07:14] [Pre-Installation] Adobe_Flash_13,0,0,206_EN_01 Installation completed with exit code [5000]. As for the -1, I believe I will have to use that method of dual deployments... something I try to stay away from since it can cause some clutter and confusion. It IS showing that the -1 errors are slowly decreasing, which I would assume is due to a user eventually logging into that machine for the install to go through. sc2013 May 7, 2014 at 6:42 AM is there any code we can put in under post-installation to check if there's a user currently logged on or not?? sort of like if a user is currently logged on , popup a notification and check if any opened programs need to be closed before installing softwares, else if no one is logged on now, just go ahead and proceed and install... doum May 7, 2014 at 9:52 AM you can use a custom global condition setting type : script data type : boolean script language : Windows powershell [bool] (Get-Process explorer -ea 0) after I create, for each application, two deployment types, using the same sources, one "silent" only when no user is logged on, with the condition = false, installation progrram visibility hidden, and one interactive, only when a user is logged on, with the condition = true, installation program visibility normal, and you select "allow users to view and interact with the program installation" sc2013 May 8, 2014 at 4:48 AM wouldnt it be easier just put it down with one deployment and put if conditions into ps1 then? $a= [bool] (Get-Process explorer -ea 0) if$a -eq "true" {} else {} doum May 8, 2014 at 8:03 AM no, because you have to select "allow users to view and interact with the program installation" and you can select that only if you deploy only when a user is logged on but I want that an unused PC gets software upgrade too, it's not logical to wait days for a user, and installing the software after the user has logged in. so for that you have to create two deployment types (maybe we can do better but I have not find how) Lipid_Venom May 8, 2014 at 7:18 PM That sounds like a great work around Doum, but I'm not sure I am understanding where you create this global condition. Is it a powershell script, if so could you show me, or is it a condition you create within SCCM for the deployment? doum May 8, 2014 at 7:21 PM not in the script, on the deployment type in SCCM you create once, after you can use it for all your deployment Brachus12 May 19, 2014 at 4:37 PM sintaxasn wrote: The first exit code 5000 is being passed back by the Toolkit - it means the user chose to Defer the install. The second however, I suspect is ServiceUI.exe itself. This is one of the reasons we never integrated ServiceUI completely - we saw some strange behaviour that frankly, we don't know how to fix since we didn't write ServiceUI or fully understand the trickery it's using the elevate. Does the deployment always fail on those machines or just once and works the next time? Hopefully it's intermittent and you can live with it when the retry happens. Oh! It's quite possible that if no user is logged on, ServiceUI is failing and returning -1. You could maybe solve this by having two deployment types, one for if a user is logged on, and one when not. Use ServiceUI if the user is logged on, and just use Deploy-Application.exe when no user is logged on. The toolkit will work in silent mode if no user is logged in. Hope this helps. Dan We're getting this "-1" error on Windows 32bit systems that DO have a user logged in at the time, and yes, we're using the 32bit version of serviceUI. sintaxasn May 20, 2014 at 1:38 PM Does it happen if you run ServiceUI manually from the command-line? If that works, can you also try using PSExec (www.sysinternals.com) to start ServiceUI using the SYSTEM account? I believe the parameters would be something like: PSExec.exe -s -i C:\Test\ServiceUI.exe C:\Test\Deploy-Application.exe Regards, Dan Brachus12 May 20, 2014 at 3:48 PM Believe it worked from command line and it also worked if the user clicked on "Retry" in the SCCM Software Center. I did notice that when that occurred, the AppEnforce.log shows it is executing "with user context" as opposed to the failing automated deploy which is "with system context". sintaxasn May 20, 2014 at 4:42 PM Hmmm, do you have it set to Install for System when the user is logged on or Install for User? It should be the former unless all your users have admin rights. Brachus12 May 20, 2014 at 6:18 PM Edited May 20, 2014 at 6:21 PM Install for system Whether or not a user is logged on Normal Same as what jockebr has listed in his first post. We're slowly transitioning end users away from being local admins, so we're currently a mix right now. doum May 20, 2014 at 6:40 PM doum wrote: you can use a custom global condition setting type : script data type : boolean script language : Windows powershell [bool] (Get-Process explorer -ea 0) after I create, for each application, two deployment types, using the same sources, one "silent" only when no user is logged on, with the condition = false, installation progrram visibility hidden, and one interactive, only when a user is logged on, with the condition = true, installation program visibility normal, and you select "allow users to view and interact with the program installation" For information, I find a problem (due to, for me, a bug in SCCM) today With this method, you can't select an application to be installed during OSD task sequence....I think it's because one of the deployment type is "only when a user is logged on". It's a bug because the another deployment type should work well, but the application is not visible in the deployment task, you can't select it. I'm working with another guy to find a workaround based on this solution http://www.petervanderwoude.nl/post/install-user-targeted-applications-during-os-deployment-via-powershell-and-configmgr-2012/ but for computer targeted application (we don't use user targeting) philschwan Jun 13, 2014 at 12:56 PM doum, did you make any progress on the solution for Task Sequences? I've run into exactly the same issue, and I'm curious to see if an Application with the interactive settings on the Deployment Type will install fine if targeted via a variable list instead of being called out as a specific task (since the latter can't be done through the GUI because of the bug you described). I'm going to test that scenario here shortly, I just wondered if you'd gotten any further along. sintaxasn Jun 13, 2014 at 1:23 PM Let me just chime in on this - I saw the exact same issue and ended up having to duplicate applications being deployed through TS as packages. It's a lot of hassle to maintain but it works Nozuka Jun 13, 2014 at 1:48 PM Edited Jun 13, 2014 at 2:06 PM philschwan wrote: doum, did you make any progress on the solution for Task Sequences? I've run into exactly the same issue, and I'm curious to see if an Application with the interactive settings on the Deployment Type will install fine if targeted via a variable list instead of being called out as a specific task (since the latter can't be done through the GUI because of the bug you described). I'm going to test that scenario here shortly, I just wondered if you'd gotten any further along. I actually had the exact same idea. But sadly it did not work with a variable list :( But maybe i did something wrong. edit: never mind, it seems to work. i had to set the following on the application: "Allow this application to be installed from the Install Application task sequence action without being deployed" and for the variable list i followed this guide: http://schadda.blogspot.ch/2012/02/sccm-2012-deploy-multiple-applications.html philschwan Jun 13, 2014 at 2:49 PM For core apps I don't have a problem with that approach; in fact I do it quite often because the Packages tend to work more consistently in OSD. The problem for me comes with doing application mapping for Refresh/Replace. philschwan Jun 13, 2014 at 2:51 PM Nozuka wrote: I actually had the exact same idea. But sadly it did not work with a variable list :( But maybe i did something wrong. edit: never mind, it seems to work. i had to set the following on the application: "Allow this application to be installed from the Install Application task sequence action without being deployed" and for the variable list i followed this guide: http://schadda.blogspot.ch/2012/02/sccm-2012-deploy-multiple-applications.html Excellent! I'm testing it right now and hoping it works the same. philschwan Jun 13, 2014 at 5:38 PM Using the PowerShell global condition provided above (two DTs: one for user interaction, one without), so far I'm getting an error "No matching policy assignments received." I did verify that the "Allow this application...." setting is enabled, so I'm trying a few other things just to make sure. I didn't see any evidence of it getting to the point of evaluating the requirements, so I don't think that's the issue. Nozuka, did you have multiple Deployment Types for the app in question? doum Jun 13, 2014 at 6:03 PM Edited Jun 13, 2014 at 6:06 PM philschwan wrote: doum, did you make any progress on the solution for Task Sequences? I've run into exactly the same issue, and I'm curious to see if an Application with the interactive settings on the Deployment Type will install fine if targeted via a variable list instead of being called out as a specific task (since the latter can't be done through the GUI because of the bug you described). I'm going to test that scenario here shortly, I just wondered if you'd gotten any further along. Hi, unfortunately, no luck :/ Impossible to deploy applications during OSD. Microsoft is really annoying sometime, and I stay politically correct... We have tried to do it like the guy done, we get list of applications to deploy, so it seems to work, but applications don't install It is unthinkable to duplicate each application to make version "OSD Compatible" So for now I search for a solution to accelerate the first SCCM agent check after that OSD has finished, so that it will deploy the applications more quickly. If someone find something.... dlynch Jun 13, 2014 at 6:08 PM The way I do it is add a script during osd that drops the machine into a collection including an unknown computer. This collection will have my required app deployments that will Install 5 minutes after osd has completed. It is a decent work around and by passes discovery as the resource is is immediately part of the deployment. Sent from my Windows Phone Nozuka Jun 16, 2014 at 7:11 AM philschwan wrote: Using the PowerShell global condition provided above (two DTs: one for user interaction, one without), so far I'm getting an error "No matching policy assignments received." I did verify that the "Allow this application...." setting is enabled, so I'm trying a few other things just to make sure. I didn't see any evidence of it getting to the point of evaluating the requirements, so I don't think that's the issue. Nozuka, did you have multiple Deployment Types for the app in question? yes, i'm using the powershell scripts from above to check if a user is logged in. but i only tested this tasksequence on already up and running machines. did you try it during OSD? i have yet to verify that this would work aswell. jockebr Jun 16, 2014 at 8:32 AM Are you all experiencing problems with the solution I suggested, using ServiceUI.exe in combination with Deploy-Application.exe? That is really strange, I have not had a single problem with that, not once. And I have used this with many different applications at several different customer sites. I'm actually building a new SCCM installation as I'm writing this, and I have about 10 or so applications so far and they all run with PSADT + ServiceUI.exe. And it works perfectly, both with regular deployments as well as in task sequences. Nozuka Jun 16, 2014 at 12:52 PM Edited Jun 16, 2014 at 12:53 PM Nozuka wrote: philschwan wrote: Using the PowerShell global condition provided above (two DTs: one for user interaction, one without), so far I'm getting an error "No matching policy assignments received." I did verify that the "Allow this application...." setting is enabled, so I'm trying a few other things just to make sure. I didn't see any evidence of it getting to the point of evaluating the requirements, so I don't think that's the issue. Nozuka, did you have multiple Deployment Types for the app in question? yes, i'm using the powershell scripts from above to check if a user is logged in. but i only tested this tasksequence on already up and running machines. did you try it during OSD? i have yet to verify that this would work aswell. sadly it did not work during OSD. i'm going to try it like this now: priority 1: deployment with "User is logged on" and the powershell script to verify that priority 2: deployment with "no user logged on" but no script to verify. because if a user was logged on, P1 would have run already. jockebr Jun 16, 2014 at 2:09 PM Nozuka, have you tried using ServiceUI.exe? Do you experience problems with that? Nozuka Jun 16, 2014 at 2:19 PM jockebr wrote: Nozuka, have you tried using ServiceUI.exe? Do you experience problems with that? no i didn't try that yet, because it didn't sound very reliable in this topic. but i might give it a try if i can't get it to work without it. jockebr Jun 16, 2014 at 2:55 PM Nozuka wrote: jockebr wrote: Nozuka, have you tried using ServiceUI.exe? Do you experience problems with that? no i didn't try that yet, because it didn't sound very reliable in this topic. but i might give it a try if i can't get it to work without it. If you have the chance, please try and let us know if it worked or not. I would be very interested to know how it works. I'm puzzled why some people seem to have problems with this, while it is working perfectly for me so far. philschwan Jun 16, 2014 at 6:03 PM Testing now with the ServiceUI.exe solution, so we'll see how it turns out. philschwan Jun 16, 2014 at 8:28 PM Using ServiceUI.exe worked perfectly in the OSD Task Sequence, and then successfully tested as a standard deployed app. Looks like I'll be moving this direction so long as the apps behave themselves. Nozuka Jun 17, 2014 at 11:47 AM jockebr wrote: Nozuka wrote: jockebr wrote: Nozuka, have you tried using ServiceUI.exe? Do you experience problems with that? no i didn't try that yet, because it didn't sound very reliable in this topic. but i might give it a try if i can't get it to work without it. If you have the chance, please try and let us know if it worked or not. I would be very interested to know how it works. I'm puzzled why some people seem to have problems with this, while it is working perfectly for me so far. i finally tried it too. much easier than i thought and seems to work. will have to see how it plays out in a larger deployment. thank you. jockebr Jun 17, 2014 at 12:42 PM I'm glad it worked for you both. In my experience this is a very reliable solution that I have used in several different SCCM installations with numerous different applications. I have not had a single problem with it. So I would be very interested to know if anyone runs into a problem, please report it here and let's see if we can figure out what's wrong. sintaxasn Jun 17, 2014 at 2:01 PM Hey guys, We've been investigating alternatives to ServiceUI since we we'd rather have native PowerShell code than a C++ exe that we don't have the source code to. I've been doing a bunch of investigation and there's some interesting info on exactly how ServiceUI works here: http://blogs.technet.com/b/cameronk/archive/2010/04/27/creating-a-user-interactive-task-sequence-experience.aspx Furthermore, Joe Bialek has a very interesting PowerShell script, Invoke-TokenManipulation which is actually half the battle: https://github.com/clymb3r/PowerShell/blob/master/Invoke-TokenManipulation/Invoke-TokenManipulation.ps1 There's two issues with Joe's script, one of which I've solved CreateProcessWithTokenW / CreateProcessAsUserW spawn a new process and immediately exits the function. We need to wait for the newly created process to complete and pass back an exit code to SCCM. Here's my additions for Win32 functions as well as an excerpt from the main script: # Win32Functions $WaitForSingleObjectAddr = Get-ProcAddress kernel32.dll WaitForSingleObject$WaitForSingleObjectDelegate = Get-DelegateType @([IntPtr], [UInt32]) ([UInt32]) $WaitForSingleObject = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($WaitForSingleObjectAddr, $WaitForSingleObjectDelegate)$GetExitCodeThreadAddr = Get-ProcAddress kernel32.dll GetExitCodeThread $GetExitCodeThreadDelegate = Get-DelegateType @([IntPtr], [Int32].MakeByRefType()) ([Bool])$GetExitCodeThread = [System.Runtime.InteropServices.Marshal]::GetDelegateForFunctionPointer($GetExitCodeThreadAddr,$GetExitCodeThreadDelegate) # Excerpt from Create-ProcessWithToken $ProcessInfo = [System.Runtime.InteropServices.Marshal]::PtrToStructure($ProcessInfoPtr, [Type]$PROCESS_INFORMATION) [UInt32]$Infinite = "0xFFFFFFFF" $Result =$WaitForSingleObject.Invoke($ProcessInfo.hProcess,$Infinite) if ($Result -ne 0) { Throw "Call to$FunctionName failed" } [Int32]$ExitCode = 0$Result = $GetExitCodeProcess.Invoke($ProcessInfo.hProcess, [Ref]$ExitCode) if (($Result -eq 0) -or ($ExitCode -eq 0)) { Throw "Call to GetExitCodeProcess failed" } Write-Host "Exit Code is$exitCode" You can simulate running as SYSTEM under Session 0 using the following from an elevated command-prompt - create a local user called SomeUser with Standard User rights: PsExec.exe -s PowerShell.exe -command "& { . C:\Test\Invoke-TokenManipulation.ps1; Invoke-TokenManipulation -CreateProcess 'C:\windows\System32\WindowsPowerShell\v1.0\powershell.exe' -ProcessArgs '-File C:\Testing\Deploy-Application.ps1' -Username 'SomeUser' -Verbose }"  And that's when we hit our second issue. The script will bounce from Session 0 to the user session - however, the user privileges remain as the Standard User. Let's read a small excerpt from the MSDN article on how this can be fixed. Keep in mind, Winlogon is referenced below, although the Invoke-TokenManipulation script is just looking for the user directly - this can be fixed with a bit of work to look for Winlogon. All proof of concept at this point Elevating token privileges with SE_DEBUG_NAME Once a handle to Winlogon is obtained, an Access Token can then be extracted. First, a template containing the privileges we require is necessary (LUID type); this will be used when creating/duplicating our Access Token (TOKEN_PRIVILEGES object). Use LookupPrivilegeValue to find the LUID representing SE_DEBUG_NAME Create a new TOKEN_PRIVILEGES object Call DuplicateTokenEx using the handle from our user’s Winlogon; our desired access is MAXIMUM_ALLOWED Call SetTokenInformation with the previously extracted Session ID (where our UI will execute) Call AdjustTokenPrivileges to merge/append privileges from the LUID template, into our duplicated token So, my knowledge of the Win32 API is a bit limited and I'm kinda stuck here. If anyone wants to help out, feel free to get in touch. In the meantime, I'm going to continue working on this aspect and see if we can get this all native PowerShell, and Sean is going to work on re-integrating ServiceUI. This might be in development for a while and we'll definitely need people's help with testing this so that we can have it rock solid stable for PSAppDeployToolkit v4 :) Dan PowerSheller Jun 17, 2014 at 10:49 PM Hi all, I've just resurrected the work we did on this previously to build the ServiceUI functionality in to the Toolkit, with improved code, logic and logging. This is a beta v4, and it's available to download from the latest "Source Code". The toolkit now calls ServiceUI to invoke itself with interaction in the system context (session 0) if the following conditions are met: the script is running in the system context (session 0) a user is logged on a task sequence is not running the deploymentmode has not been set to noninteractive by the SCCM admin The benefit of building this in to the toolkit is that all the logic is internal to the toolkit, you simply run it and it figures out what to do, plus you get full logging. We think this is going to be a major feature if we get it right, but we want to make sure that it's 100% stable, so we would really appreciate you guys downloading the latest source, testing it and providing us with your feedback. Thanks, Sean Nozuka Jun 24, 2014 at 11:42 AM Edited Jun 24, 2014 at 11:50 AM Had some problems with ServiceUi.exe after all... couldnt get it to run on 32bit machines. Which is why i tried this new beta version of the toolkit. This works well when i run it myself. But when i try to deploy it as an SCCM Application it fails. Here's the log: [24-06-2014 11:48:48] [Initialization] _Officeatwork_4.3SP2__ setup started. [24-06-2014 11:48:48] [Initialization] Script [C:\Windows\ccmcache\k\AppDeployToolkit\AppDeployToolkitExtensions.ps1] dot-source invoked by [C:\Windows\ccmcache\k\AppDeployToolkit\AppDeployToolkitMain.ps1] [24-06-2014 11:48:48] [Initialization] _Officeatwork_4.3SP2__ script version is [1.0.0] [24-06-2014 11:48:48] [Initialization] Deploy Application script version is [4.0] [24-06-2014 11:48:48] [Initialization] The following non-default parameters were passed to [Deploy Application]: [-DeploymentType Install -AllowRebootPassThru True] [24-06-2014 11:48:48] [Initialization] App Deploy Toolkit Main script version is [4.0] [24-06-2014 11:48:48] [Initialization] App Deploy Toolkit Extensions version is [1.0.0] [24-06-2014 11:48:48] [Initialization] PowerShell version is [3.0 x64] [24-06-2014 11:48:48] [Initialization] PowerShell host is [ConsoleHost version 3.0] [24-06-2014 11:48:48] [Initialization] OS version is [Microsoft Windows 7 Enterprise 64-Bit 6.1.7601] [24-06-2014 11:48:48] [Initialization] Hardware platform is [Virtual:VMWare] [24-06-2014 11:48:48] [Initialization] Computer name is [W7X64VM101] [24-06-2014 11:48:48] [Initialization] Current user is [WWZ\W7X64VM101$] [24-06-2014 11:48:48] [Initialization] Current Culture is [de-CH] and UI language is [DE] [24-06-2014 11:48:48] [Initialization] Deployment type is [Installation] [24-06-2014 11:48:48] [Initialization] Script [C:\Windows\ccmcache\k\AppDeployToolkit\AppDeployToolkitMain.ps1] dot-source invoked by [C:\Windows\ccmcache\k\Deploy-Application.ps1] [24-06-2014 11:48:48] [Initialization] The following users are logged on to the system: xxx\administrator [24-06-2014 11:48:49] [Initialization] Invoking ServiceUI to provide interaction in the system session... [24-06-2014 11:48:49] [Initialization] Executing [C:\Windows\ccmcache\k\AppDeployToolkit\ServiceUIx64.exe -Process:Explorer.exe C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -File "C:\Windows\ccmcache\k\Deploy-Application.ps1" -DeploymentType Install -AllowRebootPassThru True]... [24-06-2014 11:48:49] [Initialization] Working Directory is [C:\Windows\ccmcache\k\AppDeployToolkit] [24-06-2014 11:48:49] [Initialization] Execution completed with return code -1. [24-06-2014 11:48:49] [Initialization] ServiceUI: Matched Processes [24-06-2014 11:48:49] [Initialization] ServiceUI: Process Found: [explorer.exe] ID [4112] SESSION [1] [24-06-2014 11:48:49] [Initialization] ServiceUI: [winlogon.exe] Session: [1] PID [500] [Target Session [1] = Match] [24-06-2014 11:48:49] [Initialization] ServiceUI: Program to launch : [C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe] [24-06-2014 11:48:49] [Initialization] ServiceUI: Command line : [C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -File C:\Windows\ccmcache\k\Deploy-Application.ps1 -DeploymentType Install -AllowRebootPassThru True] [24-06-2014 11:48:49] [Initialization] ServiceUI: API [CreateProcessAsUser] Error: [5] [24-06-2014 11:48:49] [Initialization] ServiceUI returned exit code [-1] [24-06-2014 11:48:49] [Initialization] _Officeatwork_4.3SP2__ Installation completed with exit code [-1]. [24-06-2014 11:48:49] [Initialization] ----------------------------------------------------------------------------------------------------------  any ideas? Nozuka Jun 24, 2014 at 12:52 PM As a sidenote: While sadly it does not fix my problem, i found a mistake in the "Deploy-Applications.ps1" File. The Example says: .EXAMPLE Deploy-Application.ps1 -DeploymentMode "Silent" But the Parameter is: .PARAMETER DeployMode Nozuka Jun 27, 2014 at 3:53 PM Nozuka wrote: Had some problems with ServiceUi.exe after all... couldnt get it to run on 32bit machines. Still the same problem. Tried the exact same with a "Package" instead of Application now and it works perfectly on 32bit machines too. Even recreated the Application, but no luck. Guess i'll have to use a Package then. PowerSheller Jul 5, 2014 at 10:06 PM We're trying to get to the bottom of the issues with ServiceUI and I think we're close to fixing it but we need a bit of help from the community to test. I've updated the latest v4 beta. Could you do us a favour and run the following tests: -Run the latest v3 toolkit using as a 64-bit installation -Run the latest v4 toolkit as a 64-bit installation. -Run the latest v4 toolkit as a 64-bit installation launching 32-bit PowerShell. -Run the latest v4 toolkit as a 64-bit installation launching PowerShell.exe -File "Deploy-Application.ps1" instead of the Deploy-Application.exe We need to establish if the access denied message with ServiceUI is because ServiceUIx64 doesn't play well at all with ccmexec.exe, ServiceUIx86 doesn't play well with ccmexec 64-bit, or it has something to do with Deploy-Application.exe or the PSArchitecture. Your support would be much appreciated. PS - I'm working without an SCCM lab at the moment which is why I can't do these tests myself - anyone got a cloud based lab they're willing to give me access to ?! TorstenM Jul 6, 2014 at 2:10 PM I could also help testing those scenarios, but I can only find v 3.1.4 for download. Where can I get v4 (beta)? PowerSheller Jul 6, 2014 at 4:25 PM Great stuff, you can find the latest version in the sources tab. Thanks. markbow Jul 7, 2014 at 3:18 PM I would like to test this also but when I go to the Sources location to download, the v4 Beta is not available to download, can you point me in the right direction please? sintaxasn Jul 7, 2014 at 3:24 PM Click Source Code on the nav bar at the top, then click the Download button. This will pull the latest sources. Dan mmashwani Jul 10, 2014 at 12:55 AM Edited Jul 10, 2014 at 12:59 AM Edit: NVM, someone already found and posted this above :), I guess I scrolled through too fast. Someone has done a really nice job coding this in PowerShell using C# code. Here is a blog on the script: http://clymb3r.wordpress.com/2013/11/03/powershell-and-token-impersonation/ Here is the script: https://github.com/clymb3r/PowerShell/tree/master/Invoke-TokenManipulation I would probably rename his function to something that makes a bit more sense, such as: Invoke-ProcessWithLogonToken The script will list all available logon token and let you choose which one you want to use to create a new process. For the use case being discussed here, we want to use the logon token of the person that is the console user (one actively using the computer at the moment and not simply logged into another non-active session). I forget the name of the Windows API, but there is one which identifies the session ID of the user that is the active console user. Then you can use this session ID to find the username from a Windows process associated with that session id/user. That lets you know what logon token to use for creating your new process. I can look up the Windows API for discovering the active console user if there is any interest in developing a PowerShell based solution for this instead of using ServiceUI.exe. mmashwani Jul 10, 2014 at 4:12 AM Edited Jul 10, 2014 at 6:41 AM So I dug around a bit in some old code I had and found the name of the Windows API which gives you the session ID of the console user, this is the user with control of the physical mouse, keyboard, and monitor on the system. I hope this is useful information and not something that has already been figured out. Win API Function: WTSGetActiveConsoleSessionId There is some code for it referenced here: http://gallery.technet.microsoft.com/scriptcenter/e8c3af96-db10-45b0-88e3-328f087a8700 Here is a small excerpt: [DllImport("kernel32.dll", SetLastError = false, CharSet = CharSet.Auto)] public static extern int WTSGetActiveConsoleSessionId(); Some Notes On Sessions: In Vista or Later: The first user to log on gets a Session ID of 1. Each successive user that logs on gets a Session ID of 2, 3, etc. A Session ID of 0 is reserved for services. If XP: The first user to log on gets a Session ID of 0. If using Fast User Switching, additional users might get Session IDs of 1, 2, etc. Services also have a Session ID of 0. The Console Session (actively logged in user) can dynamically switch based on user switching. WTSGetActiveConsoleSessionId should always give you the correct Console Session ID at the time of the call. This API will also return a -1 if there is no active user logged into the interactive session (that is, logged in locally to the physical machine, as opposed to using RDP). The windows shell is almost always explorer.exe but during imaging of PCs, the shell can sometimes be different. You can find out what the current Windows shell is from here: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell Then you can use WMI or an API call to get the ProcessOwner, or Domain\Username, of the Windows Shell which matches the Session ID that we got from WTSGetActiveConsoleSessionId. Now we know which user's privilege token to use for creating new processes. Also, I've used the GetUserNameA function in ADVAPI32.dll to find out if I am in the SYSTEM context or not. It returns "SYSTEM" if the process is running under the SYSTEM account. dersonc Jul 10, 2014 at 10:56 PM Hi, I was checking this discussion and I think that there could be another way to do this with the CreateProcessAsUserW alternative that Dan suggested: Always set the deployment type to run without interaction in the SCCM application and setting the option as whether or not a user is logged on. Always launch the toolkit under the session 0 running as SYSTEM. Inside the toolkit detect whether or not a user is logged on. If a user is logged on set it to interactive mode otherwise no. If no interactive mode is enabled the installation will proceed without any prompts under the SYSTEM user. If the interactive mode is enabled then only launch the user interaction part in the user mode, as balloons and dialogs. The process running under the user mode would be responsible to send a response back to the process running as SYSTEM. The installation and any other part that doesn't interact with the user would still run under the SYSTEM process in this case. This doesn't require launching the process as admin under the user context to perform the installation. Do you guys think it's possible to achieve the functionality by proceeding this way? My company has been using serviceui.exe to allow user interaction on installations. In this case we always have to check the option to run the process as 32 bit. This is what we found so far: We were able to successfully view the process under the user session in all cases only on Windows 7 64 bits. If using Windows 7 32 bits serviceui.exe always fails with exit code -1 on the AppEnforce.log. If using Windows XP 32 bits the installation is successful only if the user is directly connected to the session. If connected using remote desktop to Windows XP 32 bits serviceui.exe will also fail with exit code -1 on the AppEnforce.log (we think it's due to this error: http://wishmesh.com/2011/08/createprocessasuser-fails-on-windows-xp-with-system-error-233/). Anderson Cassimiro PowerSheller Jul 10, 2014 at 11:32 PM @mmashwani, Not sure how much time you have to spend on this, but sounds like you're up to speed on your Win APIs. Sintaxasn had put together some code above on this, if you were able to build on it with your findings that would be really appreciated! @Anderson, We already have the logic around when interaction is needed and when not, the difficulty is in breaking out of session 0 using the logged on user's credentials token to show a UI. We're losing faith in ServiceUI - there's just no documentation or support around it. mmashwani Jul 11, 2014 at 12:08 AM Edited Jul 15, 2014 at 4:58 PM @Anderson The -1 exit codes you are seeing sounds like ServiceUI.exe is not able to detect a logged on user because it's using this API to detects logged on users: WTSGetActiveConsoleSessionId . Why it is not working on Win 7 32 bits seems like a bug in ServiceUI.exe perhaps. See below info: WTSGetActiveConsoleSessionId should always give you the correct Console Session ID at the time of the call. This API will also return a -1 if there is no active user logged into the interactive session (that is, logged in locally to the physical machine, as opposed to using RDP). Also, I think this is the appropriate API to use to determine if a user is logged on to a machine or not. An RDP user should not be presented with prompts to make decisions about a machine. The user in control of the machine via keyboard, mouse, monitor should be making those decisions. @PowerSheller I probably don't know as much as I should, but I will see how much time I can spend on this. Finishing up a project right now so pretty busy but will do my best. I've dealt with this issue as a packager in the WinXP world before and would like a PowerShell based solution for this. Posting serviceui.exe notes for reference: Execute program interactively in target session. Must run from SYSTEM context. If no session is specified, program will run in session connected to keyboard/mouse (console). Usage: serviceui [-nowait] [ [-session:] | [-process:] program [arg(x)] -nowait Don't wait for program completion. Exit code will not be captured. -session Specify session number to launch in. -process Search for process; program will launch in same session. program Name of application to execute. arg(x) Argument(s) for program. Examples: serviceui %windir%\notepad.exe serviceui -session:1 %windir%\notepad.exe serviceui -process:calc.exe %windir%\notepad.exe "\"my file.txt\"" serviceui -process:calc.exe "%windir%\notepad.exe" "\"my file.txt\"" mmashwani Jul 15, 2014 at 5:30 PM Going through this thread, I'm having a hard time figuring out what problem people are noticing with ServiceUI.exe. Can someone explicitly describe the problem? I would like to help in solving this if possible. Also, looking at the Deploy-Application.wse file, we can pass actual exit codes to the parent process using this code Document Type: WSE item: Global Version=9.02 Flags=00000100 Languages=65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Copy Default=1 Japanese Font Name=MS Gothic Japanese Font Size=9 Start Gradient=0 0 255 End Gradient=0 0 0 Windows Flags=00000100000000000010110000001010 Message Font=MS Sans Serif Font Size=8 Pages Modified=00001000011000000000000000000000 Extra Pages=00000000000000000000000000010000 Disk Label=Default Disk Filename=SETUP Patch Flags=0000000000000001 Patch Threshold=85 Patch Memory=4000 MIF PDF Version=1.0 MIF SMS Version=2.0 FTP Cluster Size=20 Per-User Version ID=1 Dialogs Version=7 Crystal Format=10111100101100000010001001001001 Variable Name1=_INIT_WINDOW_ Variable Default1=HIDE Variable Flags1=00001000 Variable Name2=_SYS_ Variable Default2=C:\Windows\system32 Variable Flags2=00001000 Variable Name3=_WIN_ Variable Default3=C:\Windows Variable Flags3=00001000 Variable Name4=_WISE_ Variable Default4=C:\Program Files\Altiris\Wise Package Studio\WiseScript Editor Variable Flags4=00001000 Requested Execution Level=asInvoker end item: Remark Text=Call "kernel32.dll" and pass it %#PROCEXITCODE#%. "Kernel32.dll" then terminates current process and passes %#PROCEXITCODE#% to parent process end item: Set Variable Variable=#PROCEXITCODE# Value=%PROCEXITCODE% end item: Call DLL Function Pathname=%SYS32%\kernel32.dll Function Name=ExitProcess Argument List=20#PROCEXITCODE# Return Variable=2 Flags=00100000 end  Also, as Wise only compiles 32-bit exes, we can disable WOW64 file redirection so that we can directly access 64-bit files/directories from a 32-bit process using this code: Document Type: WSE item: Global Version=9.02 Flags=00000100 Languages=65 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Copy Default=1 Japanese Font Name=MS Gothic Japanese Font Size=9 Start Gradient=0 0 255 End Gradient=0 0 0 Windows Flags=00000100000000000010110000001010 Message Font=MS Sans Serif Font Size=8 Pages Modified=00001000011000000000000000000000 Extra Pages=00000000000000000000000000010000 Disk Label=Default Disk Filename=SETUP Patch Flags=0000000000000001 Patch Threshold=85 Patch Memory=4000 MIF PDF Version=1.0 MIF SMS Version=2.0 FTP Cluster Size=20 Per-User Version ID=1 Dialogs Version=7 Crystal Format=10111100101100000010001001001001 Variable Name1=_INIT_WINDOW_ Variable Default1=HIDE Variable Flags1=00001000 Variable Name2=_SYS_ Variable Default2=C:\Windows\system32 Variable Flags2=00001000 Variable Name3=_WIN_ Variable Default3=C:\Windows Variable Flags3=00001000 Variable Name4=_WISE_ Variable Default4=C:\Program Files\Altiris\Wise Package Studio\WiseScript Editor Variable Flags4=00001000 Requested Execution Level=asInvoker end item: Remark Text=If you need to disable WOW64 file redirection so that you can access 64-Bit OS components and directories on 64-bit systems, use the following code end item: If/While Statement Variable=ENV_64BITOS Value=1 end item: Remark Text=Disable WOW64 File Redirection end item: Call DLL Function Pathname=%SYS32%\kernel32.dll Function Name=Wow64DisableWow64FsRedirection Argument List=70OLD64FSVALUE Return Variable=2ERRCODE64FS Flags=01100000 end item: End Block end item: Remark Text=Execute/Access 64-bit or 32-bit OS components and directories here. end item: Remark end item: If/While Statement Variable=ENV_64BITOS Value=1 end item: Remark Text=Enable WOW64 File Redirection end item: Call DLL Function Pathname=%WIN%\SysWow64\kernel32.dll Function Name=Wow64RevertWow64FsRedirection Argument List=21%OLD64FSVALUE% Return Variable=2ERRCODE64FS Flags=00100000 end item: End Block end  PowerSheller Jul 15, 2014 at 10:18 PM The truth is we don't understand why ServiceUI is failing, but when it does fail invariably the error message is this: [Initialization] ServiceUI: API [CreateProcessAsUser] Error: [5] The issue appears to be related to cross-architecture processes. When we launch ServiceUI from ccmexec to launch the toolkit it seems to work, but when we launch ServiceUI from within the toolkit it fails - the ideal is that we build it in to the toolkit and the toolkit re-launches itself using ServiceUI provided the following criteria are met: running in system context user is logged on task sequence is not running There is some further background and test results in this thread that help explain what happens in each scenario: https://psappdeploytoolkit.codeplex.com/discussions/546142 Nozuka Jul 29, 2014 at 8:59 AM Edited Jul 29, 2014 at 9:04 AM dersonc wrote: My company has been using serviceui.exe to allow user interaction on installations. In this case we always have to check the option to run the process as 32 bit. This is what we found so far: We were able to successfully view the process under the user session in all cases only on Windows 7 64 bits. If using Windows 7 32 bits serviceui.exe always fails with exit code -1 on the AppEnforce.log. Anderson Cassimiro We are having the exact same problem with 32bit Machines. But only if we run the Deployment as an Application. It works fine when using a Package. Not sure why this is happening. dersonc Aug 14, 2014 at 6:43 PM Hi Sean, Since ServiceUI is not being reliable wouldn't the other solution proposed by @sintaxasn with the CreateProcessWithTokenW / CreateProcessAsUserW work better? In this case just display the user interface on the user session and continue running the rest of the script and the installation with the SYSTEM account context. Anderson Cassimiro PowerSheller Aug 20, 2014 at 3:29 PM Hi Anderson, If you can write the code to get this to work, we'd be happy to integrate it. Thanks, Sean jonward08 Aug 26, 2014 at 4:36 PM Edited Aug 26, 2014 at 4:37 PM I have gotten the ServiceUI.exe solution in the OP to work in my environment, with one caveat. I use both version of ServiceUI.exe I use the 64-bit version to call Deploy-Application.EXE when installing on x64 machines, and use the 32-bit version to call Deploy-Application.EXE when installing on x86 machines. So far it has worked great. We can use the same application to deploy to end user UI and also to OSD task sequences. No need to select "Run installation and uninstall as 32-bit process on 64-bit clients" rtruss Sep 26, 2014 at 4:12 PM OK, so I think I have found the thread I am looking for but after reading the entire thing 1) my brain hurts a bit ;) and 2) still have no idea if anything has been resolved with this. I love this tool and am working hard to get our cm12 app creation team to use it but here is how we have to use it. We use the application model with only a very few exceptions, drivers usually. Need to deploy apps multiple ways (some apps get used in all scenarios at the same time): All users collection Specific computer collections OSD I do not want to maintain 2 apps, one for users and one for system/OSD deploys as that would be a HUGE mess. We have 11 different versions of office alone due to all the languages we need. I found this most wonderful tool right when it was on the cusp of version 3.1.5 So I am relatively new to it but have spent a lot of time reading on it, working with it and testing apps galore. I now am on v3.2.0 as it seems to have some other fixes in place and one I thought was to address this very situation. I have 1 app that will work as needed, deployed to a computer collection and still allow user interaction. None of the other items I test are working that same way, ugh. Later today I will be confirming that my deploy-application.ps1 files are correct as taken from the download source files on this site. I must be missing something. Do I maybe need to enable the Run installation and uninstall as 32-bit process on 64-bit clients option? Now lets complicate this further ;) (we are IT its what we do). I want to have the 'core' files centrally located on all the computers in my site, makes long term management easier so say I want it like this C:\windows\Brunswick\AppDeployToolKit and in it will be every file needed to run the deploy-application.ps1 script. So far works GREAT, unless i try to use deploy-application.exe :( It says it cant locate the files. Is there a way to pas a path to the exe so it can locate the source code? thanks in advance for everyone's hard work on this most excellent adventure (I mean tool) ChristianM82 Nov 6, 2014 at 12:55 PM Hi all, I'm using ServiceUI.exe with Deployment toolkit (Ver. 3.2). User Experience is configured like this: Install for System Whether or not a user is logged on Normal I have a problem in this situation: OSD was succesfull no user is logged in The deployment of the application starts and I see this in the logfile: [06-11-2014 13:34:55] [Initialization] Session 0 not detected. [06-11-2014 13:34:55] [Initialization] Installation is running in [Interactive] mode. .... [05-11-2014 09:45:13] [Pre-Installation] User has the option to defer. Is it possible to improve this part between line 4959 - 4978 in AppDeployToolkitMail.ps1 to set the mode to NonInteractive in this case? ChristianM82 Nov 6, 2014 at 1:57 PM Is there a reason why the deployMode is not set to "NonInteractive" in the Else-Part (at line 4933) current code: 4933 Else { 4934 Write-Log "No User is logged on" 4935 } my suggestion: 4933 Else { 4934$deployMode = "NonInteractive" 4935 Write-Log "No User is logged on, setting deployment mode to [$deployMode]." 4936 } sintaxasn Nov 6, 2014 at 4:19 PM Hi Christian, Can you download the latest 3.5 release from the Source Code section and test this? We have made numerous changes to user detection - I think we have this fixed. 3.5 should be released as Stable in the next few days. Thanks, Dan ChristianM82 Nov 7, 2014 at 8:57 AM Hi Dan, I'm sorry, but it is still not working: [Initialization] :: Get session information for all logged on users. Get-LoggedOnUser 07.11.2014 09:53:15 1 (0x0001) [Initialization] :: No users are logged on to the system PSAppDeployToolkit 07.11.2014 09:53:15 1 (0x0001) [Initialization] :: Unable to load COM Object [Microsoft.SMS.TSEnvironment]. Therefore, script is not currently running from a SCCM Task Sequence. PSAppDeployToolkit 07.11.2014 09:53:15 1 (0x0001) [Initialization] :: Session 0 detected, process running in user interactive mode: deployment mode will not be set to [NonInteractive] PSAppDeployToolkit 07.11.2014 09:53:15 1 (0x0001) [Initialization] :: Installation is running in [Interactive] mode. PSAppDeployToolkit 07.11.2014 09:53:15 1 (0x0001) ChristianM82 Nov 7, 2014 at 11:03 AM I take a look to your Script: Line 178: [boolean]$IsProcessUserInteractive = [System.Environment]::UserInteractive When I start Deploy-Application.EXE by using ServiceUI.exe, I think Line 178 returns "true". Is there is reason why you don't set $deployMode always to NonInteravtive if Session 0 is detected? benG Nov 7, 2014 at 1:34 PM Mh, dunno if i'm wrong but here's what i configured my applications: Application Model, Deployment Type: Install for system, whether or not a user is logged on, visibility: Normal I CAN interact with the PSApp Toolkit (e.g. defer / close... blah) AND i'm also able to install these Applications within a OSD Task Sequence... I'm using PS Appdeploy 3.2.0 mmashwani Nov 7, 2014 at 3:53 PM The detection is working as intended. We don't always set$deployMode to 'NonInteractive' if in session 0 because it is possible to have interaction with the user even when in session 0. That's exactly what ServiceUI.exe allows. ServiceUI.exe allows you to interact with a user from session 0. It seems like you wanted to override the automated detection of the installer interaction level and always have $deployMode be 'NonInteractive'. You can manually set$deployMode to 'NonInteractive' by specifying this parameter when calling your Deploy-Application.ps1 script like: -DeployMode 'NonInteractive'. ChristianM82 Nov 7, 2014 at 4:22 PM Edited Nov 7, 2014 at 4:58 PM No, that's not what I want. I'm deploying the applications to users. If the computer is at the desk, the user should be able to defer the script. If the computer is new I'm using "User Device Affinity" and set the primary user for the device. After the Task Sequence has finished, SCCM installs all the applications wich are deployed to the primary user. Nobody is logged on. Now the script starts and hangs at: [Pre-Installation] User has the option to defer. mmashwani Nov 7, 2014 at 5:36 PM Edited Nov 7, 2014 at 5:41 PM I see what you mean. We need to add another if statement to set the deployMode to non-interactive if there are no users logged in. Replace this line: Write-Log -Message "Session 0 detected, process running in user interactive mode." -Source $appDeployToolkitName With this: If (-not$usersLoggedOn) { $deployMode = 'NonInteractive' Write-Log -Message "Session 0 detected, process running in user interactive mode, no users logged in: deployment mode set to [$deployMode]." -Source $appDeployToolkitName } Else { Write-Log -Message "Session 0 detected, process running in user interactive mode." -Source$appDeployToolkitName } ChristianM82 Nov 11, 2014 at 2:27 PM In Ver. 3.2? mmashwani Nov 11, 2014 at 10:07 PM In the beta 3.5 on the Source page. I just pushed an update in git so the latest 3.5 beta should have this fix now. Please test with that. ChristianM82 Nov 13, 2014 at 8:48 AM looks like that 3.5 is broken. If I run the downloaded script and run Deploy-Application.ps1 I got this: Resolve-Error : The term 'Resolve-Error' 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 C:\Temp\psappdeploytoolkit-8360e31d022d3c69478310ccac6e5e729ecfcf59\Toolkit\ Deploy-Application.ps1:172 char:33 + [string]$mainErrorMessage = "$(Resolve-Error)" + ~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (Resolve-Error:String) [], Comma ndNotFoundException + FullyQualifiedErrorId : CommandNotFoundException benG Nov 13, 2014 at 10:23 AM I don't know if this is the same issue but it comes from the same direction. Here is what i want: Deploy Software to Devices e.g. Adobe Flash Users should be prompted to close e.g. IE -> therefore i need to setup the DT to "Install for System & Only when a user is logged on & allow users to interact blabla" What i also want to do: Install the exact Application during my Task Sequence OSD Staging Process. The problem is that i can't select the Applications in the TS Editor unless i set the DT to "run whether or not a user is logged on" So, as of now i have to create 2 Applications 1x for a Deployment with PSAppToolkit 1x for the OSD Deployment... Is there no way around this? Deployment of Adobe Flash to logged on Users: [13-11-2014 11:08:36] [Initialization] Adobe_FlashPlayer_15.0.0.223_MUI_01 setup started. [13-11-2014 11:08:36] [Initialization] Script [C:\Windows\ccmcache\x\AppDeployToolkit\AppDeployToolkitExtensions.ps1] dot-source invoked by [C:\Windows\ccmcache\x\AppDeployToolkit\AppDeployToolkitMain.ps1] [13-11-2014 11:08:36] [Initialization] Adobe_FlashPlayer_15.0.0.223_MUI_01 script version is [1.0.0] [13-11-2014 11:08:36] [Initialization] Deploy Application script version is [3.2.0] [13-11-2014 11:08:36] [Initialization] The following non-default parameters were passed to [Deploy Application]: [-DeploymentType Install] [13-11-2014 11:08:36] [Initialization] App Deploy Toolkit Main script version is [3.2.0] [13-11-2014 11:08:36] [Initialization] App Deploy Toolkit Extensions version is [1.0.0] [13-11-2014 11:08:36] [Initialization] PowerShell version is [2.0 x86] [13-11-2014 11:08:36] [Initialization] PowerShell host is [ConsoleHost version 2.0] [13-11-2014 11:08:36] [Initialization] OS version is [Microsoft Windows 7 Enterprise 32-Bit 6.1.7601] [13-11-2014 11:08:36] [Initialization] Hardware platform is [Physical] [13-11-2014 11:08:36] [Initialization] Computer name is [DEBEW036] [13-11-2014 11:08:36] [Initialization] Current user is [MYDOMAIN\DEBEW036$] [13-11-2014 11:08:36] [Initialization] Current Culture is [de-DE] and UI language is [DE] [13-11-2014 11:08:36] [Initialization] Deployment type is [Installation] [13-11-2014 11:08:36] [Initialization] Script [C:\Windows\ccmcache\x\AppDeployToolkit\AppDeployToolkitMain.ps1] dot-source invoked by [C:\Windows\ccmcache\x\Deploy-Application.ps1] [13-11-2014 11:08:36] [Initialization] The following users are logged on to the system: MYDOMAIN\grothe [13-11-2014 11:08:36] [Initialization] Session 0 detected. [13-11-2014 11:08:36] [Initialization] Installation is running in [NonInteractive] mode. Deployment of MS Office to logged on Users: [13-11-2014 10:59:13] [Initialization] Microsoft_Office_2013_x86_MUI_01 setup started. [13-11-2014 10:59:14] [Initialization] Script [C:\Windows\ccmcache\r\AppDeployToolkit\AppDeployToolkitExtensions.ps1] dot-source invoked by [C:\Windows\ccmcache\r\AppDeployToolkit\AppDeployToolkitMain.ps1] [13-11-2014 10:59:14] [Initialization] Microsoft_Office_2013_x86_MUI_01 script version is [1.0.0] [13-11-2014 10:59:14] [Initialization] Deploy Application script version is [3.2.0] [13-11-2014 10:59:14] [Initialization] The following non-default parameters were passed to [Deploy Application]: [-DeploymentType install] [13-11-2014 10:59:14] [Initialization] App Deploy Toolkit Main script version is [3.2.0] [13-11-2014 10:59:14] [Initialization] App Deploy Toolkit Extensions version is [1.0.0] [13-11-2014 10:59:14] [Initialization] PowerShell version is [2.0 x64] [13-11-2014 10:59:14] [Initialization] PowerShell host is [ConsoleHost version 2.0] [13-11-2014 10:59:14] [Initialization] OS version is [Microsoft Windows 7 Enterprise 64-Bit 6.1.7601] [13-11-2014 10:59:14] [Initialization] Hardware platform is [Physical] [13-11-2014 10:59:14] [Initialization] Computer name is [DEBEN043] [13-11-2014 10:59:14] [Initialization] Current user is [MYDOMAIN\DEBEN043$] [13-11-2014 10:59:14] [Initialization] Current Culture is [de-DE] and UI language is [DE] [13-11-2014 10:59:14] [Initialization] Deployment type is [Installation] [13-11-2014 10:59:14] [Initialization] Script [C:\Windows\ccmcache\r\AppDeployToolkit\AppDeployToolkitMain.ps1] dot-source invoked by [C:\Windows\ccmcache\r\Deploy-Application.ps1] [13-11-2014 10:59:14] [Initialization] The following users are logged on to the system: MYDOMAIN\administrator [13-11-2014 10:59:14] [Initialization] Session 0 not detected. [13-11-2014 10:59:14] [Initialization] Installation is running in [Interactive] mode. ChristianM82 Nov 13, 2014 at 10:34 AM This is exactly what we talk about. Use ServiceUI.EXE to run the Deploy-Application.EXE. Use this settings: Program: ServiceUI.exe "Deploy-Application.EXE" Install for System Whether or not a user is logged on Normal benG Nov 13, 2014 at 10:58 AM Thanks for making this more clear to me. How do you handle the uninstallation? serviceui.exe "deploy-application.exe uninstall" doesn't work. ChristianM82 Nov 13, 2014 at 11:48 AM Tyr it with this: ServiceUI.exe "Deploy-Application.EXE" "–DeploymentType" “Uninstall” jockebr Nov 13, 2014 at 11:52 AM benG wrote: Thanks for making this more clear to me. How do you handle the uninstallation? serviceui.exe "deploy-application.exe uninstall" doesn't work. Remove the quotation marks and use this: ServiceUI.exe Deploy-Application.exe Uninstall jockebr Nov 13, 2014 at 11:54 AM I haven't written in this thread in a long time. As many people have pointed out, ServiceUI.exe does not seem to work well in 32-bit Windows for some reason. It works perfectly in 64-bit, so if you're only using that (which you should, it's almost 2015 now people :) ) you're good to go. If you however must use 32-bit Windows, a workaround is to use psexec.exe instead of ServiceUI.exe. That works well. benG Nov 13, 2014 at 12:06 PM I still have some old 32 Bit XP Machines out there... but.. maybe i just replace them instead of keeping updating... mmashwani Nov 13, 2014 at 12:32 PM The error with Resolve-Error looks like the script can't find the Resolve-Error cmdlet in AppDeployToolkitMain.ps1. Can you make sure you're using the latest beta 3.5 version of AppDeployToolkitMain.ps1? mmashwani Nov 13, 2014 at 12:56 PM Also, I came across this tool the other day. It's the ServiceUI.exe equivalent from BigFix...now owned by IBM. It's a freely available utility. I wonder if it works just fine in 32/64-bit environments. https://www-304.ibm.com/support/docview.wss?uid=swg21506033 ChristianM82 Nov 13, 2014 at 12:59 PM mmashwani wrote: The error with Resolve-Error looks like the script can't find the Resolve-Error cmdlet in AppDeployToolkitMain.ps1. Can you make sure you're using the latest beta 3.5 version of AppDeployToolkitMain.ps1? It looks like that Deploy-Application.ps1 doesn't invoke AppDeployToolkitMain.ps1. ChristianM82 Nov 13, 2014 at 1:16 PM I found the problem, it's line 45: Set-ExecutionPolicy -ExecutionPolicy 'ByPass' -Scope 'Process' -Force -ErrorAction 'SilentlyContinue' It returns: Set-ExecutionPolicy : Windows PowerShell updated your execution policy successfully, but the setting is overridden by a policy defined at a more specific scope. Due to the override, your shell will retain its current effective execution policy of Unrestricted. Type "Get-ExecutionPolicy -List" to view your execution policy settings. For more information please see "Get-Help Set-ExecutionPolicy". At line:1 char:1 + Set-ExecutionPolicy -ExecutionPolicy 'ByPass' -Scope 'Process' -Force -ErrorActi ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ + CategoryInfo : PermissionDenied: (:) [Set-ExecutionPolicy], Sec urityException + FullyQualifiedErrorId : ExecutionPolicyOverride,Microsoft.PowerShell.Com mands.SetExecutionPolicyCommand mmashwani Nov 13, 2014 at 1:27 PM That's very strange. So even though it's set to silently continue upon error, you're saying that the script fails at this point because of an attempt change the execution policy. The policy set via GPO takes precedence and the execution policy is not changed, but your script stops executing. If that is the case, then I guess we just have to take that line out so people that define their policy via GPO can run the script. ChristianM82 Nov 13, 2014 at 1:38 PM I think -ErrorAction has no effect. Here is what I have found: The ErrorAction parameter has no effect on terminating errors (such as missing data, parameters that are not valid, or insufficient permissions) that prevent a command from completing successfully. Source: http://technet.microsoft.com/en-us/library/dd315352.aspx mmashwani Nov 13, 2014 at 1:43 PM Does the script work for you if you put the line in a Try/Catch block? Try { Set-ExecutionPolicy -ExecutionPolicy 'ByPass' -Scope 'Process' -Force -ErrorAction 'Stop' } Catch {} ChristianM82 Nov 13, 2014 at 2:02 PM That works :) mmashwani Nov 13, 2014 at 2:14 PM Great, thanks, fix implemented in beta. jlapchuk Nov 25, 2014 at 6:14 PM Where can we download the latest version of the beta? I'm working with v4.00 released 8/4 and am experiencing the issue with ServiceUI returning error code 5 on 32-bit machines. mmashwani Nov 25, 2014 at 7:29 PM There is currently no beta. We just released 3.5 as final yesterday. The beta 4.00 beta release you downloaded before probably never made it to 4 and the changes got incorporated into some other version release. ledge4 Nov 26, 2014 at 3:13 PM ServiceUI and exit codes seems to work better on Win7 32-bit machines when KB2506143 is installed, at least for me. jhedelin Dec 9, 2014 at 10:03 AM Is it possible to run ServiceUI.exe with custom script? We have 2 different scripts, one for win7 and one for win8 The command lines are: Deploy-Application.exe Deploy-Application-Win7.ps1 Install Deploy-Application.exe Deploy-Application-Win8.ps1 Install But its not working with ServiceUI.exe. ServiceUI.exe Deploy-Application.exe Deploy-Application-Win7.ps1 Install RorySRut Dec 11, 2014 at 12:49 AM This is a great thread. Could someone verify that the solution at this point in time is the below? And if I have only 64-bit OS machines, is it better to use the 64-bt version of serviceUI or use the 32-bit version and check the appropriate box in the CM application configuration? Install: ServiceUI.exe "Deploy-Application.EXE" Uninstall: ServiceUI.exe Deploy-Application.exe Uninstall Install for System Whether or not a user is logged on Normal jockebr Dec 11, 2014 at 8:45 AM RorySRut wrote: This is a great thread. Could someone verify that the solution at this point in time is the below? And if I have only 64-bit OS machines, is it better to use the 64-bt version of serviceUI or use the 32-bit version and check the appropriate box in the CM application configuration? Install: ServiceUI.exe "Deploy-Application.EXE" Uninstall: ServiceUI.exe Deploy-Application.exe Uninstall Install for System Whether or not a user is logged on Normal Yes, that works. Siocnarf Dec 11, 2014 at 1:25 PM Hi, Is it possible to synthetize the problem and the solution. There is a lot of informations. From the documentation: Deploy-Application.ps1 Performs the actual install / uninstall and is the only file that needs to be modified, depending on your level of customisation. Deploy-Application.exe An optional executable that can be used to launch the Deploy-Application.ps1 script without opening a PowerShell console window. Supports passing command-line parameters to the script.  Is it any difference between both way? That thread is very long and interesting but there is a lot of informations and test so it might be hard to fully understand the problem and the solution. François PowerSheller Dec 11, 2014 at 1:51 PM All, One or two people on this thread have had positive experience using ServiceUI. We found it to be unreliable in our testing so scrapped including it in the toolkit. Instead we have decided to provide user interaction in system context using scheduled tasks. Embedding this functionality in to the toolkit bad several advantages over launching the toolkit with ServiceUI. The source code tab contains the latest source code which we expect to release as v4 beta next week. We woul appreciate if you could take the time to do some tests with this and let us know how you get on. Cheers, Sean RorySRut Dec 15, 2014 at 10:56 PM When using ServiceUI.exe, do you need to check if someone is loggedon in the .ps1 script? Or does it work fine if no one is logged on? RorySRut Dec 15, 2014 at 10:59 PM Sorry to be a dummy. What would I need to do to test the not yet release v4 beta? Not exactly sure what I should download from the 'sources' tab. Or is there a document that tells me what to do? RorySRut Dec 16, 2014 at 12:56 AM Before I dive into testing different scenarios, if I wanted to pass the parameters to deploy-application.exe whe using serviceui.exe, what would the syntax be? Using the below for install did not work. When I took all of the parameters off then it worked. ServiceUI.exe Deploy-Application.exe -DeploymentType Install -DeployMode Interactive -AllowRebootPassThru \$false jlapchuk Dec 24, 2014 at 12:03 AM I've tested out the latest beta, and it works, provided that the logged on user is an admin on the machine. However, most users I'm using PSAppDeploy on are NOT local admins, so the deployment fails to run properly. Am I missing something? How do I properly deploy this latest version using SCCM? I'm currently using: Install: Deploy-Application.EXE Uninstall: Deploy-Application.exe Uninstall Install for System Whether or not a user is logged on Normal jlapchuk Dec 29, 2014 at 10:03 PM After further testing with v3.6.0, I think I've got everything working to properly display UI to the current logged on user of a machine. In SCCM, I have the following set: Install: Install.bat Uninstall: Uninstall.bat Install for System Whether or not a user is logged on Normal Here are the command lines for each bat file: Install: PSExec.exe -si -accepteula %cd%\ServiceUI.exe %cd%\Deploy-Application.exe Uninstall: PSExec.exe -si -accepteula %cd%\ServiceUI.exe %cd%\Deploy-Application.exe Uninstall I also have copies of both PSExec.exe and ServiceUI.exe (x86 version) at the root of the toolkit. So far I've had success on both 64-bit and 32-bit machines. For some reason, running PSExec as SYSTEM, then running ServiceUI after, avoids the usual "Error Code 5" on 32-bit machines. The implementation may be a bit cumbersome, but it DOES WORK. If anyone else is interested, feel free to do the same. benG Dec 30, 2014 at 9:38 AM Hummm, so you use PSExec because you had issues using ServiceUI on 32/64 Machines? I use this the 32-bit ServiceUI to deploy Applications to 32 Bit AND 64 Bit Windows 7 / XP with no issues so far. And this also works during a TS for me... jlapchuk Dec 30, 2014 at 5:23 PM Correct, I consistently receive failed deployments on 32-bit machines, all with Error code 5 from ServiceUI, similar to what others on this thread have posted as well. While we are working to transition to a complete 64-bit environment, the workaround with using PSExec in conjunctions with ServiceUI seems to do the trick. plepleple Jan 6, 2015 at 11:41 AM I am currently testing out the solution supplied by jlapchuk with Office 2013 and it seems to be working. It's not especially cumbersome imo. So far I've only verified it to be working when testing on a "standalone VM" with a little help of the sticky keys trick (replace sethc.exe with cmd.exe) to the silent install scenario. But I'm doing a SCCM deployment right now, and I'm pretty confident that it will work just as fine. Big thanks for this awesome toolkit and keep up the good work! Also thank you jlapchuk for sharing your test results. plepleple Jan 6, 2015 at 3:43 PM Edited Jan 6, 2015 at 3:45 PM I have now tested both OSD installation and with user logged on using the same SCCM application and deployment type and I can confirm that it does work. I did however encounter an issue while testing the logged on user scenario. The built in service Interactive Services Detection (UI0Detect.exe) kicks in and alerts the user of what's going on (read more on UI0Detect here). Pat Altimore who wrote the blog post linked above actually mentions a possible cause for this, which is running the x86 version of ServiceUI on a x64 system. I will do some more testing and I think the solution simply is running the x64 version of serviceui on x64 versions of Windows. Sorry if this has already been mentioned here. This thread has grown pretty big :).. jlapchuk Jan 6, 2015 at 3:48 PM Edited Jan 6, 2015 at 3:49 PM Interesting, I haven't been experiencing that in my environment. I do however, have "Run installation and uninstall program as 32-bit process on 64-bit clients" checked on my deployment types. However, if you wanted to modify the bat files to run the appropriate ServiceUI depending on OS architecture, that should work as well. dersonc Jan 21, 2015 at 6:26 PM @jlapchuk I have been testing your approach with the bat files and it works fine for me on both 32 and 64 bits but I'm only able to see any user interface if the user is connected through a console session. While connected through RDP nothing is shown. Did you test this scenario? jlapchuk Jan 26, 2015 at 10:22 PM I have tested this using RDP and had the same issue, no UI for RDP users. Have you tried running mstsc /console? ChristianM82 Jan 27, 2015 at 6:35 AM ServicesUI.exe displays the interface in the console session, not in the RDP session. The Interface is there, but you can't see or interact with it. plepleple Jan 28, 2015 at 3:08 PM Edited Jan 28, 2015 at 3:13 PM A small update on my front - regarding the Interactive Service Detection service. Sorry for the delay, but I've been swamped with work. I switched over to x64 based version of ServiceUI and all my UI problems are gone since. I still have the install.bat though, but I guess I should just change the install command to in the DT but as of now that is still on the todo list. Our client farm consists exclusively of x64 based versions of Windows (mixed 7 and 8.1), so I'm not concerned with a OS architecture detection part of the batch. I'm sure though that would solve it for a mixed platform environment. "Run installation and unins .... as 32-bit process on 64-bit clients" has been ticked all along btw.. Edit: read through the thread a bit and realize that jlapchuks solution is only concerning x86 clients. So conclusion on my part: as long as you're not dealing with x86 clients in your environment, there's no need for psexec and a batch wrapper - at least not my experience. jlapchuk Jan 28, 2015 at 6:06 PM Correct, my solution is only intended for mixed environments and only for deployments using the Application model. If all your machines are 64-bit, or you're using the Package model for deployments, then there's no need for ServiceUI and the batch files. scotpower Feb 3, 2015 at 5:59 PM (Apologies if this requires a new thread) I am running into a problem solely with the Show-InstallationPrompt dialogs displaying under session 0, and only with PowerShell 3.0 or 4.0. The Show-InstallationPrompt dialogs, when run under session 0 (via ConfigMgr 12 or pesexec) with PowerShell 3.0 or 4.0 on Win7x64 either fail for display, or sometimes will display up to 10 minutes later. All other dialogs are presented as expected. Has anyone expierned this problem, and if so, have any idea what may going on here. Jyrisi Mar 19, 2015 at 7:20 AM scotpower wrote: (Apologies if this requires a new thread) I am running into a problem solely with the Show-InstallationPrompt dialogs displaying under session 0, and only with PowerShell 3.0 or 4.0. The Show-InstallationPrompt dialogs, when run under session 0 (via ConfigMgr 12 or pesexec) with PowerShell 3.0 or 4.0 on Win7x64 either fail for display, or sometimes will display up to 10 minutes later. All other dialogs are presented as expected. Has anyone expierned this problem, and if so, have any idea what may going on here. There is a bug in 3.6.0: https://psappdeploytoolkit.codeplex.com/workitem/172