creating a shortcut on a remote desktop, but the shortcut is created with a "file" instead of "file folder" as the "target type" - powershell

I'm trying to create a shortcut on a remote desktop in the domain here, and I'm a domain admin. If I run the following code directly on the target machine, the shortcut can be created and is able to lead me to the target path.
$shortcutpath3 = "c:\Users\Public\Desktop\Shortcuts to Test Custom\VV 1211 -TC.lnk"
$WshShell3 = New-Object -comObject WScript.Shell
$Shortcut3 = $WshShell3.CreateShortcut($shortcutpath3)
$Shortcut3.TargetPath = "\\machine\testcustom\"
$Shortcut3.Save()
I saved this script as test.ps1, run it with folloing code on a different mahchine. The code ends without any errors/warings, and the shortcut is created on the target machine with the propeties i specified. But it cannot lead me to the target place, it actually ask me to pick a program to open that file. I compared the properties of the 2 shortcuts, and found that the "target type" of the broken shortcut is "file" while it is "file folder" for a good shortcut.
Invoke-Command -ComputerName TARGETSERVER -FilePath test.ps1
Any idea how i can fix this? And why is this happening? Thank!!!

I had the same problem and and I used Get-Item to make it work. Try this:
$targetPath = Get-Item("\\machine\testcustom\")
$WshShell3 = New-Object -comObject WScript.Shell
$Shortcut3 = $WshShell3.CreateShortcut($shortcutpath3)
$Shortcut3.TargetPath = $targetPath.FullName
$Shortcut3.Save()

Since you're a domain admin I'd strongly recommend doing this with a Group Policy Preference. You can restrict shortcut creation to particular users/groups/computers/etc. via item-level targeting.

I've been battling this for the past several hours, Googling to no avail. For posterity, here's my summary. While alternatives suggestions are appreciated:
PowerShell inexplicably has no direct way to create a shortcut. It can create symbolic link, but 1) it requires admin rights, and 2) it behaves differently.
Group Policy Preferences are great--but only if your machines are in office or routinely on a VPN.
If you're trying to create a shortcut to a network folder, setting the TargetPath to that folder only works if the computer actually can reach it when the script runs, i.e. same issue as with Group Policy Preferences. PowerShell will create the shortcut, but the Target Type will be a File rather than a File Folder (and I found no info online how to control that; trailing slash or not doesn't matter).
The behavior of running these code suggestions varies depending whether you run this interactively or as a script.
Here's what I found does work:
Set the $shortcut.TargetPath to "C:\Windows\Explorer.exe"
Add a line: $shortcut.Arguments = """Target folder""" (the """ are needed as an escape character for the shortcut to show as C:\Windows\Explorer.exe "Target folder")
So for your example above, the following should work (assuming permissions to c:\Users\Public\Desktop):
$shortcutpath3 = "c:\Users\Public\Desktop\Shortcuts to Test Custom\VV 1211 -TC.lnk"
$WshShell3 = New-Object -comObject WScript.Shell
$Shortcut3 = $WshShell3.CreateShortcut($shortcutpath3)
$Shortcut3.TargetPath = "C:\Windows\Explorer.exe"
$shortcut.Arguments = """\\machine\testcustom\"""
$Shortcut3.Save()

Related

Powershell Startup Script GPO Not Applying

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.

Create " *.url " file using powershell and CMD

i was inquiring if there are options to create a url shortcut to be placed on c:\users\username\favorites to be applied to be added to the login script of the user on Active directory to create the favorites for any user
i tried searching all over the internet and i only found "MD" and "MKDir" commands
Not the most PowerShell answer but this is the widely used one with the best compatibility in versions. Much like this answer but small changes for URLs
$WshShell = New-Object -comObject WScript.Shell
$Shortcut = $WshShell.CreateShortcut("$Home\Favorites\Google.url")
$Shortcut.TargetPath = "http://www.google.ca"
$Shortcut.Save()
This will make a shortcut to Google in your favorites. $Home being one of PowerShell's Automatic Variables
If you happen to have PowerShell 5.0 it can now do this natively. Again refer to this answer for more information

Boxstarter or PowerShell command to change "Opens With" properties

I'm trying to develop my own Boxstarter script for spinning up new machines. I just realized that I'd really like to add a line that will change default applications to open certain file types. For example, I want to open .txt files with Notepad++. I know how to do this by right-click the file and checking it's properties, but is there a line I can add to my Boxstarter script that will do it? Or, since Boxstarter is basically a special set of PowerShell commands, is there a PowerShell command I can invoke directly to change the opens with property? I did some searching, and most of the results were about how to get PowerShell to open something, not change the opens with property. The rest were all about how to open PowerShell.
Another similar, but not quite the same, way to go about this is to change the file association you want to associate with a particular applicaition. Chocolatey includes some helper commands to do this and is therefore available to your Boxstarter package. Here is an excerpt from one of my Boxstarter packages:
Install-ChocolateyFileAssociation ".txt" "$env:programfiles\Sublime Text 2\sublime_text.exe"
Install-ChocolateyFileAssociation ".dll" "$($Boxstarter.programFiles86)\jetbrains\dotpeek\v1.1\Bin\dotpeek32.exe"
So now double clicking on any text file opens sublime or any dll opens dotpeek.
But I agree. Its still helpful to be able to add to the "Open With..." list.
Thanks to #Raf for pointing me in the right direction. Here's the code to change the OpensWith property of .txt files:
$principal = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$key = [Microsoft.Win32.Registry]::CurrentUser.OpenSubKey("Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice",[Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::ChangePermissions)
$acl = $key.GetAccessControl()
$right = "SetValue"
$denyrule = New-Object System.Security.AccessControl.RegistryAccessRule($principal,$right,"DENY")
$ret = $acl.RemoveAccessRule($denyrule)
$ret = $key.SetAccessControl($acl)
Set-ItemProperty -Path HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.txt\UserChoice -Name ProgId -Value Applications\notepad++.exe
Slightly modified from an answer in the TechNet forums.
I haven't figured out if there's a boxstarter shortcut for this, but changing the ACL rules was the key. Without it, you don't have the proper access to change this particular registry item. Even when I tried running Powershell as Admin and made sure I had all the right permissions on the UserChoice key (both the administrator account and my user account had Full Control), I kept getting an error that the Requested registry access is not allowed.

Add mstsc to shortcut target powershell

A little background about what I'm trying to do and why. We are slowly migrating from using a local copy of office on our end users Win7 machines to publishing office through RDS 2012. With 2012 you can have the end users machine subscribe to a webfeed which puts the shortcuts to the actual RDP files in Appdata. In order to have our image pretty much mirror before RDS, I need to pin the shortcuts to the taskbar. If you pin the shortcut as it comes from the RDS Gateway server the icon on the taskbar is that of the .rdp file. If you edit the target for the shortcut and put mstsc.exe before the path to the .rdp file you can then pin the shortcut to the taskbar using those icons of the shortcut.
I have found posts on how to change the target field of shortcuts but nothing on how to add something to what is currently there. An environment variable is needed since the path to the shorts will be different for each user. Below is I have tried thus far
$Word = $env:userprofile + "\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\RemoteApp and Desktop Connections\Microsoft Word 2010.lnk"
$sh = New-Object -COM WScript.Shell
$targetPath = $sh.CreateShortcut($Word).TargetPath
$sh.TargetPath = "mstsc.exe" + $targetPath ## Make changes
$sh.Save() ## Save$shell = New-Object -COM WScript.Shell
One of the errors i'm getting is : Property 'Arguments' cannot be found on this object; make sure it exists and is settable.
Any help will be greatly appreciated.
Instead of using Shell COM object, how about using a .Net wrapper class? There is a great sample.
To use the VBAccelerator's wrapper in Powershell, extract the source code and compile a DLL like so,
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe /t:library /out:ShellLink.dll /r:System.Drawing.dll .\ShellLink.cs .\FileIcon.cs
This should create ShellLink.dll, which you can add as Powershell type like so,
Add-Type -path .\ShellLink.dll
And use the class by creating a new object like so,
$lnk = new-object vbAccelerator.Components.Shell.ShellLink
$lnk.Target = "C:\Windows\System32\mstsc.exe"
$lnk.Arguments = "some arguments"
$lnk.Description = "My awesome shortcut"
$lnk.Save("c:\temp\test.lnk")
Your code will prepend "mstsc.exe" to the current target path if you just add this line before your ## Make changes line:
$sh = $sh.CreateShortcut($word)
Sounds like you also want to add a space, so that your lnk file is the "connection file" argument of mstsc.exe. You can set the Arguments property like so:
function Set-RDSshortcut {
param( [parameter(mandatory=$true)]$Shortcut )
$sh = New-Object -COM WScript.Shell
$targetPath = $sh.CreateShortcut($Shortcut).TargetPath
$targetPath = "mstsc.exe"
$sh = $sh.CreateShortcut($Shortcut)
$sh.TargetPath = $targetPath
$sh.Arguments = $Shortcut
$sh.Save()
} #end function

Powershell running under a service hangs on *.zip CopyHere

I'm running a Windows Service (Hudson) which in turn spawns a PowerShell process to run my custom PowerShell commands. Part of my script is to unzip a file using CopyHere. When I run this script locally, I see a progress dialog pop up as the files are extracted and copied. However, when this runs under the service, it hangs at the point where a dialog would otherwise appear.
Here's the unzip portion of my script.
# Extract the contents of a zip file to a folder
function Extract-Zip {
param([string]$zipFilePath, [string]$destination)
if(test-path($zipFilePath)) {
$shellApplication = new-object -com shell.application
$zipFile = get-item $zipFilePath
$zipFolder = $shellApplication.NameSpace($zipFile.fullname)
$destinationFile = get-item $destination
$destinationFolder = $shellApplication.NameSpace($destinationFile.fullname)
$destinationFolder.CopyHere($zipFolder.Items())
}
}
I suspect that because its running under a service process which is headless (no interaction with the desktop), its somehow stuck trying to display a dialog.
Is there a way around this?
If it's still actual, I managed to fix this with having CopyHere params equal 1564.
So in my case extract zip function looks like:
function Expand-ZIPFile{
param(
$file, $destination
)
$shell = new-object -com shell.application
$zip = $shell.NameSpace($file)
foreach($item in $zip.items())
{
$shell.Namespace($destination).copyhere($item,1564)
"$($item.path) extracted"
}
1564 description can be found here - http://msdn.microsoft.com/en-us/library/windows/desktop/bb787866(v=vs.85).aspx:
(4) Do not display a progress dialog box.
(8) Give the file being operated on a new name in a move, copy, or rename operation if a file with the target name already exists.
(16) Respond with "Yes to All" for any dialog box that is displayed.
(512) Do not confirm the creation of a new directory if the operation requires one to be created.
(1024) Do not display a user interface if an error occurs.
If this is running on Vista or Windows 7, popping up UI from a service isn't going to be seen by the end user as you suspected. See this paper on Session 0 Isolation. However, does the progress dialog require user input? If not, I wouldn't think that would cause the service to hang. I would look for an option to disable the progress display. If you can't find that, then try switching to another ZIP extractor. PSCX 1.2 comes with an Expand-Archive cmdlet. I'm sure there are also others available.
Looking at the documentation for PowerShell, it looks like the -NonInteractive option may help here