Familiar with PowerShell but a noob with PSAppDeployToolkit.
Grabbed the latest PSAppDeployToolkit 4.1.8
Trying to deploy Win32 app via Intune that needs to run as SYSTEM.
Need to display a custom PowerShell GUI for the user to pick one or more things from a list of 50 options.
Can you please suggest the best way to do this?
Invoke-AppDeployToolkit.ps1
#Something like these?
Start-Process powershell.exe -ArgumentList "-ExecutionPolicy Bypass -File "$($adtSession.DirFiles)\GUIScript.ps1"" -Wait -WindowStyle Normal
I tested different methods using PSEXEC to run as system and can get in working locally but when deployed via Intune can't get the GUI to display = Do I require ServiceUI? (I read that was no longer required in v4 or is that only not required for PSAppDeployKit GUI's
If I need to use ServiceUI a little guide on the best way would be fantastic. e.g.
Do I need to download ServiceUI.exe from somewhere and put it in the Files Directory?
How to call it nicely for my need?
################################################################ #Another random question; is one "better" than the other?
Here's my idea for this:
Because I don't believe it fair to ask the PSADT Guys to create a "Single-Purpose" Show-ADT function for this, I was going to build a GUI PS script that shows the list of languages, lets the user select what they want and creates a text file with the languages list
.
Execution steps:
This GUI PS script is launched with PSADT's Start-ADTProcessAsUser before the Proofing Tools MSI is launched and waits. (It waits by default, BTW)
The user select what language(s) they want.
The GUI PS script creates a text file with the languages in a predetermined location (e.g. c:\Program Data\PSADT\PTLanguages.txt) and terminates.
The front script (Invoke-AppDeployToolkit.ps1) then looks for the text file with the languages in that predetermined location.
If found, it reads the contents and launches the Proofing tools MSI and feeds that list to that MSI Property. If not found, it aborts.
FYI: It's not as sexy or secure as using a software pipe like the guys did in V4 but it's simple to understand. The front script would (Invoke-AppDeployToolkit.ps1) would have to clean up the predetermined location before and after selection.
Not that this helps you in the immediate moment, but there is a feature request for PSADT to show checkboxes on the Show-ADTInstallationPrompt dialog, which 'may' go some way towards a workable solution for your problem (in the future). It looks like this feature request is currently on the backlog for v4.3 of the Toolkit, with v4.2 due for release sometime soon.
IMHO, only launch from PowerShell while you are testing (as you will see the log output in the PowerShell window), but for production deployments, I'd strongly recommend using the launcher Invoke-AppDeployToolkit.exe
You might want to have a general read up of the docs to familiarise yourself with the toolkits capabilities and usage, but I'll guide you to review the various launch options: How to Deploy · PSAppDeployToolkit - This is for the current v4.1.x branch of the Toolkit
FWIW, 4.2.0 has a combobox for Show-ADTInstallationPrompt which I think will cover things nicely. @Boofhead maybe hold off your package until 4.2.0 hits RTM in a week or two if you can?
I did end up setting this up, but I'm excited to try something new\better.
########################################
The gotchas for me as a PSADT noob were:
########################################
User account unable to read user script for Start-ADTProcessAsUser
My understanding is that because the app is running as SYSTEM from the Intune cache, the standard user doesn't even have read access.
I copied the script to C:\Program Files\Company\Office Proof Tools.
It seemed like a good idea to keep it in a protected directory, and I was also thinking it might help avoid any constrained language issues.
Output from the GUI script is written to ProgramData.
########################################
Unable to see Office setup.exe
Duh... I was originally going to let Office setup.exe handle closing the Office applications, but it's running as SYSTEM, so of course user can't see it.
Added:
AppProcessesToClose = @(
@{ Name = 'winword'; Description = 'Microsoft Word' }
@{ Name = 'excel'; Description = 'Microsoft Excel' }
@{ Name = 'powerpnt'; Description = 'Microsoft PowerPoint' }
@{ Name = 'outlook'; Description = 'Microsoft Outlook' }
@{ Name = 'onenote'; Description = 'Microsoft OneNote' }
@{ Name = 'msaccess'; Description = 'Microsoft Access' }
@{ Name = 'mspub'; Description = 'Microsoft Publisher' }
@{ Name = 'visio'; Description = 'Microsoft Visio' })
This has somewhat been addressed for 4.2.0. If you were to use Start-ADTProcessAsUser -FilePath setup.exe, where setup.exe is in the Files folder, we'll handle that, but if its some script in the -ArgumentList parameter, you'll still need to address that. Our Set-ADTItemPermission is there to help though.
That is indeed correct. Your setup with the AppProcessesToClose is good, and if you want to show progress, we provide Show-ADTInstallationProgress. We support differing messages, percentage values, etc. The benefit of using our progress is that all apps can share a uniform look instead of 99% all using our progress dialog vs. Office using its own.
