I have a script that I deploy using LANDesk and in the script it calls a powershell script to add a shortcut to a network folder on the user's desktop. LANDesk logs in to run the script with a local machine account but I don't want the shortcut to be put on that desktop but of the desktop of the user that is currently logged in. Is there a way to do this in powershell?
Here is my code for adding the shortcut if you run the script as the logged in user (can't run as the user themselves because they don't have admin rights)
$wshshell = new-object -comobject WScript.Shell
$Ink = $wshshell.CreateShortcut("$home\Desktop\PI_Users.lnk")
$Ink.TargetPath = "\\htntfs04\PI_Users"
$Ink.Save()
Thanks in advance for help.
If you're using LANDesk, and you're using a package to distribute the script, you can choose between executing the script as LocalSystem which is the default, or as the Current user's account.
Just open the properties of the package, go to Accounts and choose "Current user's account". The task will fail if there's no user logged in to the machine.
But, if I understand correctly, the problem is that the user is not allowed to create a link on its own desktop? If so, this solution won't work and the task would fail anyway!
Another approach I often use would be to execute a script that loops through all the local profiles and creates a link on the desktop of each user. If it's okay for you to use a WSH script instead of a powershell script, you could use something like this:
Const HKEY_LOCAL_MACHINE = &H80000002
Set objRegistry = GetObject("winmgmts:\\.\root\default:StdRegProv")
Set ws = CreateObject("Wscript.Shell")
strKeyPath = "SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList"
objRegistry.EnumKey HKEY_LOCAL_MACHINE, strKeyPath, arrSubkeys
For Each objSubkey In arrSubkeys
strValueName = "ProfileImagePath"
strSubPath = strKeyPath & "\" & objSubkey
objRegistry.GetExpandedStringValue HKEY_LOCAL_MACHINE, strSubPath, strValueName, strProfile
If Left(strProfile, Len(ws.ExpandEnvironmentStrings("%windir%"))) <> ws.ExpandEnvironmentStrings("%windir%") Then
Set objShtCut = ws.CreateShortcut(strProfile & "\Desktop\PI_Users.lnk")
objShtCut.TargetPath = "\\htntfs04\PI_Users"
objShtCut.Save
Set objShtCut = Nothing
End If
Next
Can't you use [Environment]::GetFolderPath("Desktop") to get the desktop's path for current user?
Related
Pretty basic script used to create a web shortcut on the PC's desktop, but it's not applying for some reason. I have it set in the gpo under
Computer Configuration->Policies-> Windows Settings-> Scripts-> Startup->
Added the powershell script-> And set it to run the powershell script first.
I also know the script works because I have tried running it manually on the machine without admin privileges or anything and it appears just fine.
$DesktopPath = [Environment]::GetFolderPath("Desktop") + "\Prophet21.url"
$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut($DesktopPath)
$Shortcut.TargetPath = "https://p21.gallagherseals.com/prophet21/#/login" $Shortcut.Save()
You're running the code in the wrong context, to run as a user and affect a user, you need to deploy this as a User Configuration.
When you run a Startup Script for a Computer, this happens when the PC is Domain Joined and will process shortly after displaying the initial login screen silently in the background.
But because there is no user logged in yet, some items aren't available.
To fix this, just deploy it as a User Configuration, the full path to the setting would be:
User Configuration -> Policies -> Windows Settings -> Scripts (Logon / Logoff);
The better approach
However, GPO also natively supports creating Desktop Icons with a nice and easy to use wizard. Just follow this short guide by Praj Dasai. I used to manage GPO and I would always prefer a native solution to running a script.
I've been trying to launch teams using powershell, i've succeeded launching teams using the destination path under the shortcut property, and then running it in powershell.
C:\Users\user1\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
But this only works for the local user, if i run the script with another user teams won't launch. i've storing the user in a variable.
$user = $env:UserName
C:\Users\$user\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"
This doesn't work.
So my question how can I launch teams.exe (make it visible)?
I want to make it like how you can launch word with start winword.exe
You should get the variable for the App Data folder, not just the username. Otherwise, it won't work in situations where the user's profile folder is in a different location:
$user = "$($env:LOCALAPPDATA)\Microsoft\Teams\Update.exe --processStart `"Teams.exe`""
"%LOCALAPPDATA%\Microsoft\Teams\Update.exe" --processStart "Teams.exe"
This can be fixed by using the following format instead:
$user = $env:UserName
'C:\Users\'+$user+'\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe"'
When I am running commands or installing software remotely using PowerShell - Invoke-Command etc I would like sometimes to be able to show a message on the remote screen so the user knows something is happening, or when work done etc.
I would like to if possible make this message look as professional as possible, e.g. better than just a standard winform message box if it can be done? perhaps more the style of the Windows 10 ones with coloured background and use of image if possible.
Spent a while googling but most seem to relate to using obsolete methods such as net-send or using msg.exe.
Thanks
https://michlstechblog.info/blog/powershell-show-a-messagebox/
So the issue really isnt creating the messagebox itself, its having it show on the users session.
So when you run a command against a system, youre using your creds to run the command therefore it wont show in the users session. You can get around this by running it in the users context using a task scheduler. I have a script that does all this for you but, id hate to recreate the wheel and will have to wait till monday (when im at work) to post it here.
It accepts user input in your sessions that outputs it to a vbs, which then copies it over the message to the users machine, and a task schedule is set to run immediately for the user thats logged in.
edit: The script is this without the task scheduler. I just invoke gwmi win32_computersystem | Select -ExpandProperty username to get the current user logged in and add it to the task.
#Prompt for messge
$strMSG = Read-Host -Prompt "Enter message"
#deleting vbs if it exists
del C:\brief\test.vbs
#creating vbs from scratch so it doesnt override
New-Item C:\brief\test.vbs
#Appending each the values to a seperate line
Add-Content C:\brief\test.vbs 'Set objShell = Wscript.CreateObject("WScript.Shell")'
Add-Content C:\brief\test.vbs "strText = `"$strMSG`""
Add-Content C:\brief\test.vbs 'intButton = objShell.Popup(strText,0,"Computer Support",48)'
#calling on the script
& cscript C:\brief\test.vbs
Found a great solution here which appears on quick testing to work well for displaying a toast notification on a remote machine
https://smsagent.blog/2019/06/11/just-for-fun-send-a-remote-toast-notification/
I have two different users, my regular user and my admin user. Both have profiles setup for PowerShell. I log into my workstation ONLY as my regular user. My issue is that when running PowerShell as my regular user, I can type "menu" at the prompt from any folder and it will run the Menu.ps1 script from the scripts folder. When I try running PowerShell as my admin user, I get "The Term 'menu' is not a blah blah blah". The only way I can run it is if I change the the PSDrive named scripts: and dot source execute from there.
The only difference that I can find is that my regular user has access to a windows mapped drive z: (its in the Path environment variable also), while my admin user does not. I was hoping that I would just need to add scripts:
to the environment variable but that didn't help either.
Any assistance is appreciated.
Thank You Jeff Zeitlin.
I added this to my Admin users profile, works perfectly.
$ScriptsPath = "\\Server\Share\Scripts"
$ScriptsDrive = "Z:"
$Network = New-Object -ComObject "Wscript.Network"
$Network.MapNetworkDrive("$($ScriptsDrive)","$($ScriptsPath)")
$strPath=$env:path
if (!($strPath.ToUpper().Contains($ScriptsDrive))) {
$env:path += ";" + $ScriptsDrive + "\"
}
I created PowerShell script wich install an application on computer (windows 7).
This script is in GPO and deployed with GPO at logon users. This worked fine, but I want that at the end of installation, my powershell script send at the current logged user on computer a message like "Reboot your computer please".
I tested many things but I don'tview popup, maybe because my script are execute with admin rights (not with user rights).
Test :
#$wshell = New-Object -ComObject Wscript.Shell
#$wshell.Popup("Operation Completed",0,"Done",0x1)
[Windows.Forms.MessageBox]::Show(“My message”, , [Windows.Forms.MessageBoxButtons]::OK, [Windows.Forms.MessageBoxIcon]::Information)
Your script may be popping up the message but then closing the PowerShell console immediately after, removing the popup. Try waiting on the result of the popup before closing the PowerShell instance:
$wshell = New-Object -ComObject Wscript.Shell
$result = $wshell.Popup("Operation Completed",0,"Done",0x1)
You need to load the assembly providing the MessageBox class first, and you cannot omit the message box title if you want to specify buttons and/or icons.
Add-Type -Assembly 'System.Windows.Forms'
[Windows.Forms.MessageBox]::Show(“My message”, "", [Windows.Forms.MessageBoxButtons]::OK, [Windows.Forms.MessageBoxIcon]::Information)
# ^^
You can use an empty string or $null here, but simply not providing a value (like you could do in VBScript) is not allowed.
As a side-note, I'd recommend avoiding typographic quotes in your code. Although PowerShell will tolerate them most of the time, they might cause issues sometimes. Always use straight quotes to be on the safe side.
Edit: Since you're running the script via a machine policy it cannot display message boxes to the logged-in user, because it's running in a different user context. All you can do is have a user logon script check whether the software is installed, and then display a message to the user. This works, because a user logon script running in the user's context.