Problems with VB Script

0

A while back I posted a question asking for a VB script to delete a shortcut "TeamViewer 12 Host" from anyone's and everyone's desktop if it existed. Local not remote. I ran it on my Windows 10 workstation and it worked. It even compensated for my desktop being redirected to a server. The problem is I can't get it to work on anyone else's computer. On everyone else's, even though they are local administrators, they get an Access Denied error when it tries to delete it. They too are local administrators. I have even tried running it from an elevated command prompt. No joy. The odd thing is that I can navigate to it via File Explorer and delete it no problem. Only think I can think is that it is something in the script. Any idea what is going on?

    ' Specify filename to remove from user desktops
strShortcut = "TeamViewer 12 Host.lnk"

' Create file system object
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")

' Find root of user data folder (C:\USERS on recent versions of Windows)
strUsers = objFSO.GetParentFolderName(objFSO.GetParentFolderName(objShell.SpecialFolders("Desktop")))
Set objUsers = objFSO.GetFolder(strUsers)

' Check each user folder, and look for our file in the DESKTOP subfolder
For Each objFolder In objUsers.SubFolders
    strCheck = objFolder & "\Desktop\" & strShortcut
    Wscript.Echo "Checking:" & strCheck
    ' If shortcut file exists remove it
    If objFSO.FileExists(strCheck) Then
        Wscript.Echo "Deleting:" & strCheck
        objFSO.DeleteFile(strCheck)
    End If
Next

ZiggyStardust

Posted 2017-03-16T18:04:44.220

Reputation: 29

does it help to add on error resume next to the start of the script? – HelpingHand – 2017-03-16T21:06:50.213

Answers

0

If you want to skip the problem of the redirected desktop and the permissions problem created by the "All Users" junction, you can hard-code the search directory and skip any search paths that include "All Users." Example (the two changes are marked with comments):

strShortcut = "TeamViewer 12 Host.lnk"

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objShell = CreateObject("WScript.Shell")

strUsers = "C:\Users" ' <-- or "C:\Documents and Settings" for XP, etc.
Set objUsers = objFSO.GetFolder(strUsers)

For Each objFolder In objUsers.SubFolders
    strCheck = objFolder & "\Desktop\" & strShortcut
    If InStr(strCheck, "All Users") = 0 Then ' <-- SKIP "All Users" to avoid permission problems
        Wscript.Echo "Checking:" & strCheck
        If objFSO.FileExists(strCheck) Then
            Wscript.Echo "Deleting:" & strCheck
            objFSO.DeleteFile(strCheck)
        End If
    End If
Next

Original answer:

You mentioned that your desktop is redirected to a network location. If your users have traversal rights to your network profile path (strUsers in this context), they should receive an "Access Denied" error as the For Each loop tries to delete a file from another user's redirected desktop.

Example: Deleting \\fileserver\profiles\YourUser\Desktop\TeamViewer 12 Host.lnk will be fine, but deleting \\fileserver\profiles\SomeOtherUser\Desktop\TeamViewer 12 Host.lnk will give "Access Denied."

Tanner Jotblad

Posted 2017-03-16T18:04:44.220

Reputation: 311

Does not compute. My desktop is redirected. Their's isn't. It works on mine. Doesn't work on theirs. In conjunction with that even if it were the case the error would be File Not Found and not Access Denied. Try it on your local computer. Put a "TeamViewer 12 Host" shortcut in the User\Public\Public Desktop folder and try the script. – ZiggyStardust – 2017-03-16T18:59:26.250

All our domain accounts have redirected desktops, so that was my context. Running it from a local administrator account works for me as long as the shortcut isn't on the Public desktop, in which case it still gives "Permission Denied." For your users, is the shortcut on their desktop or the public desktop? – Tanner Jotblad – 2017-03-16T21:51:07.360

The shortcut could be anywhere but as a rule it is in the Public\Desktop. You now see the problem. I can navigate to that folder and delete the icon manually but the script gives "Access Denied". That would lead me to believe that the problem is in the script. Even running the script at an elevated command prompt yield "Access Denied". – ZiggyStardust – 2017-03-17T13:03:46.123

I think the problem is the Public desktop. Because it checks folders alphabetically, it checks "All Users" before "Public," and "All Users" is a junction to "Public" with different permissions. Try putting something like this before your "Checking:" echo: If InStr(strCheck, "All Users") <> 0 Then Wscript.Echo "Skipping All Users" Else – Tanner Jotblad – 2017-03-17T13:35:33.890

That worked but actually brought up more questions. The first being why it couldn't delete from "All Users"? Local admin and ran at an elevated prompt no less but the real question.... I know why it worked on mine now. It never looked on the C: drive. It determined that my desktop was on the server and never looked at C: so it never found an "All Users" folder. I don't know enough about VB but will this script even work if a user is not logged in? – ZiggyStardust – 2017-03-17T16:10:42.387

What do you mean by a user not being logged in? Are you planning to run this once for all your existing users, or set it up to run at first login (e.g., via Group Policy)? In any case, it needs some user context to run under – Tanner Jotblad – 2017-03-17T16:25:13.127

As for why it doesn't work for "All Users," I'm guessing it's because the permissions for \All Users\Desktop (as a junction) is different than those for \Public\Desktop. Namely, "All Users" is set to give full control to administrators, but only to that folder, whereas "Public" is set to give full control to administrators on that folder and also on sub-folders and files. – Tanner Jotblad – 2017-03-17T16:27:11.887

It is going to be part of a RMM package so it will run whether a user is logged in or not. I am not sure the loop is right. I would think that the loop would be for every profile..... check the desktop for the icon. I watched the loop on my computer. It went right to the server and never looked at C:. That is why it worked on mine. If never looked in C:\All Users or anywhere on C:. Hence the question about user context. It looks like it found my profile then assumed everyone else's was in the same place. Not the case. – ZiggyStardust – 2017-03-17T19:23:24.963

The loop is fine for local users (if it skips All Users). It just doesn't work for yours because your desktop is in a different context (see the example in my answer). Which user will be running the script for your package? – Tanner Jotblad – 2017-03-21T13:13:31.890

I say your comment but I think you missed what I was referring to. The reason it worked on mine, you are correct, is because it didn't look at the All Users folder and that is a problem and a blessing. It is a blessing in that the All Users folder is a problem child and can't delete from it but the whole script is kind of useless because it doesn't look at all the profiles. – ZiggyStardust – 2017-03-21T22:13:35.650

In my case it looked and my desktop which is up on the server (redirected). It found my desktop and then stayed up on the server searching for others. It completely skipped the profiles on the C: drive and yes there were 5 or 6 on the C: drive. Folder redirection can be done per user when my Desktop is on the server but the other 5 users of this computer don't have their desktops redirected so their desktop reside on drive C:. It didn't even look at those. It looked at the current users context (mine) and then stayed on the server looking for other. It never once looked on drive C:. – ZiggyStardust – 2017-03-21T22:13:58.070

That is why I think the look control is not correct. It should loop through each profile, determine where the desktop is for that profile. Then check it for the icon. – ZiggyStardust – 2017-03-21T22:14:02.313

But it will be fine if it runs in the context of a local user and you put in logic to skip "All Users," which is why I asked which user the script would be running as. If it's you, then yes, it's not going to work as it is, in which case couldn't you just hard-code C:\Users as the root if you know that's what it's going to be for them? If it's a local administrator, then it should work fine since it will be looking at C:\ anyway. – Tanner Jotblad – 2017-03-22T21:36:15.427

There is no way of knowing what user will be logged in, if any, when the script is ran. I agree that is should be hard coded to look and loop through C:\Users and find where every users desktop if from there (and skip All Users). It can't be based on any user being logged in when it is ran. Do you know how to make the changes? – ZiggyStardust – 2017-03-23T01:13:07.253

Regardless, it needs to run as some user; it can't run as nothing. This is probably specified wherever you're setting up the script. I've updated my answer with changes. – Tanner Jotblad – 2017-03-23T14:54:47.983

It is ran as "System". I changed "Desktop" to "Profiles" and it started going through the profiles folder on the C: drive which is correct. I was hoping that when it got to my profile it would recognize that my desktop was redirected to the server and it did not. It has gotten a little complicated for my blood. Thanks for all the help. – ZiggyStardust – 2017-03-24T15:55:37.547