Shared Start Menu based on what's installed!

[FN-GM]

does not work , please find the attached.

 

Thanks

[Steve21]

does not work , please find the attached.

 

Thanks

 

Oops can you try last line as:

 

wshshell.run "robocopy " & Chr(34) & strSource & Chr(34) & " " & Chr(34) & strDest & Chr(34) & " " & Chr(34) & " /E /MIR /COPY:DATS /SECFIX /Z /W:20 /R:1"

 

Think I missed a "

 

 

Errr... It says line 2, Suggest it's your destination not complete, not mine O.o

 

Do you mind posting what you're using? or PM'ing if you don't want the name public?

 

Steve

Edited May 19, 2011 by Steve21

[FN-GM]

Oops can you try last line as:

 

wshshell.run "robocopy " & Chr(34) & strSource & Chr(34) & " " & Chr(34) & strDest & Chr(34) & " " & Chr(34) & " /E /MIR /COPY:DATS /SECFIX /Z /W:20 /R:1"

 

Think I missed a "

 

 

Errr... It says line 2, Suggest it's your destination not complete, not mine O.o

 

Steve

 

Thanks, but i get the same error.

 

Thanks

[Steve21]

Thanks, but i get the same error.

 

Thanks

 

Made an edit above:

 

Errr... It says line 2, Suggest it's your destination not complete, not mine O.o

 

Do you mind posting what you're using? or PM'ing if you don't want the name public?

 

Steve

[FN-GM]

The destination is ok, its the same as the one that works in Windows 7.

[Steve21]

The destination is ok, its the same as the one that works in Windows 7.

 

My point being it's saying your string isnt terminated aka did you miss a " etc etc.

 

As the script works here fine using a random local filepath.

 

Any chance of posting the one you're using? just incase never know!

 

Steve

[FN-GM]

Your right its me

 

This time it doesnt error out but opens the command prompt and closes quickly, no files copied.

 

Thanks

[Steve21]

Your right its me

 

This time it doesnt error out but opens the command prompt and closes quickly, no files copied.

 

Thanks

 

Is that using the original one? Or the modified one. Go back to before I editted the line and try please

 

Steve

[FN-GM]

The edited version

[Steve21]

The edited version

 

Ok getting there slowly

 

Try this version now please:

 

Dim strSource, strDest
strSource = "N:\Documents\test"
strDest = "C:\test"
Set wshShell = WScript.CreateObject ("WSCript.shell") 	
wshshell.run "robocopy " & Chr(34) & strSource & Chr(34) & " " & Chr(34) & strDest & Chr(34) & " " & " /E /MIR /COPY:DATS /SECFIX /Z /W:20 /R:11"

 

Obviously changing directories again

 

Steve

[FN-GM]

Ok getting there slowly

 

Try this version now please:

 

Dim strSource, strDest
strSource = "N:\Documents\test"
strDest = "C:\test"
Set wshShell = WScript.CreateObject ("WSCript.shell") 	
wshshell.run "robocopy " & Chr(34) & strSource & Chr(34) & " " & Chr(34) & strDest & Chr(34) & " " & " /E /MIR /COPY:DATS /SECFIX /Z /W:20 /R:11"

 

Obviously changing directories again

 

Steve

 

Does the same as before,

 

Thanks for all your input by the way

[Boredguy]

My solution was to have a network share containing all the start menu folder structure with suitable security groups to prevent students getting the SIMS icons, as well as other restrictions.

 

At logon, a vbs script clears out the local computers redirected start menu, and then looks at the remote share, loops through each subfolder and reads the target location for each shortcut. If it exists, then it copies the shortcut over to the local start menu. At the end of each folder, it checks to see if the local copy contains any lnk files, and if the folder didn't have anything copied over, it removes it to keep it nice and tidy.

 

So far our logons only take 15-20 seconds from entering the users password til their desktop appearing with correct icons showing. It also means that our XP and Windows 7 start menus keep the same layout, and when we roll out 64bit version of Windows 7, we can drop the updated application shortcuts into the network repository and know that it will only appear on the correct OS version.

[FN-GM]

Hi Guys,

 

For network applications where do you put the shortcuts? If i put them in a redirected folder on the C Drive, when a laptop is taken home the start menu will freeze because the shortcuts lead to a path that the machine can't contact.

 

How would you deal with it?

 

Thanks

[pete]

I'm pondering combining the "that's not installed, hide/don't copy the shortcut" functionality with a Monolithic start menu at \\server\menu with access-based enumeration.

 

The downside is I have to copy the menu items via a login script to say c:\documents and settings\username\start menu and point their menus there.

 

How long does the "that's install/not installed" login script take to run (on average)? Couple of seconds?

[Jamo]

I am not sure what the reason is not for using Group Policy Preferences in this instance!? Item level targetting can be set on all the shortcuts from one location based on security group/if a file exists etc. No need for scripts and redirected shares!

 

You can even add shortcuts to the quick launch and desktop if required, again with item level targetting. This is available on XP and 7 and works the same on both.

[Killer_Bot]

Managed to get this script working in most regards in that it's successfully copying files to the local drive including permissions. The only issue I'm having now is that I can't figure out the whole 'hiding' the folders thing. For example I've removed permissions for 'authenticated users' and made sure the test user had no access to certain folders/files within the Start Menu directory. When logging on as that test user, none of the folders were shown initially, including those they do have access to.

 

Trying to get our head around your script we noticed a reference to the 'desktop.ini' file existing. Copied the .ini file into the directories and then they showed when logged on as the user but those they don't have access to also showed up, though they were (empty).

 

Any ideas what I'm doing wrong?

[5tu]

Use Group Policy Preferences to sculpt the existing start menu on computer startup, you can use checks to looks for each individual .exe of each program and also automatically remove the shortcuts if the program has been uninstalled. It adds about 20 seconds to computer startup but there is no redirection or user based login scripting so an actual login is really fast. Depending on how you deploy your software you can just call gpupdate to update the start menu while users are logged in and the they can use it without a reboot.

 

I realise this thread is a bit old and morganw's post above dates back to April last year, but.....

 

I'm trying to deliver customised start menus to my Windows 7 clients using Group Policy Preferences. Each shortcut preference is set to 'Replace' mode and has 'Item Level Targeting' enabled to check if the target executable exists. This works fine.

 

However, if a user logs onto a PC that has 'Application A' installed and receives a shortcut for 'Application A', and then logs off and logs onto another PC which doesn't have 'Application A' installed, the shortcut doesn't get removed from the user's start menu. This is the case even when the preference item has 'Remove this item when it is no longer applied' selected.

 

Am I missing something?

[Killer_Bot]

I realise this thread is a bit old and morganw's post above dates back to April last year, but.....

 

I'm trying to deliver customised start menus to my Windows 7 clients using Group Policy Preferences. Each shortcut preference is set to 'Replace' mode and has 'Item Level Targeting' enabled to check if the target executable exists. This works fine.

 

However, if a user logs onto a PC that has 'Application A' installed and receives a shortcut for 'Application A', and then logs off and logs onto another PC which doesn't have 'Application A' installed, the shortcut doesn't get removed from the user's start menu. This is the case even when the preference item has 'Remove this item when it is no longer applied' selected.

 

Am I missing something?

 

I think the 'Remove this item when it is no longer applied' option applies to removing that setting when the Group Policy Object no longer targets that computer rather than the individual objects don't exist. It sounds like it may be more of an issue with their AppData storing the start menu objects. There are most likely ways you could clear out this area with a script on logon/logoff but it depends on where you've put their appdata.

[TechMonkey]

I don't know, I am literally about to start looking at this today, but at a guess I would think you need to either delete all the shortcuts each time or have some option to delete if the file isn't there.

 

I'm thinking about having a shortcut store on a share and then have a local startmenu folder that is built on boot (or logon), one for staff, one for students. This way it is station specific for the apps, but user specific also.

[AlexB]

Not sure about user specific as we use a GPo based method which only works on groups (pupils and staff in our case).

Basically we have pre created folders on the C drive with shortcuts in (pushed via machine GPPs). When a user logs in it runs a script to check for the existance %appdata%\Microsoft\Windows\Start Menu\Programs\ and if it doesn't exist it creates a symbolic link to where the shortcuts are hidden away. e.g.

 

if not exist "%appdata%\Microsoft\Windows\Start Menu\Programs\" if exist "c:\startmenus\" linkd.exe "%appdata%\Microsoft\Windows\Start Menu\Programs\" "c:\startmenus\"

 

This way we get different sub folders for staff and pupils without having to worry about all the shortcuts being in user profiles, allowing us to only edit one location to tidy up shortcuts.

 

I should probably mention that we hide the all users start menu items from users.

 

This can be extended to as many groups as you like, e.g. you could have a music_students group and they get another subfolder on the start menu.

[5tu]

I think the 'Remove this item when it is no longer applied' option applies to removing that setting when the Group Policy Object no longer targets that computer rather than the individual objects don't exist. It sounds like it may be more of an issue with their AppData storing the start menu objects. There are most likely ways you could clear out this area with a script on logon/logoff but it depends on where you've put their appdata.

 

Thanks for your response Killer_Bot. I did think about this. Roaming AppData for students is redirected to their home directory so this could be emptied on logoff. However, on staff accounts I've left Roaming AppData in their profile so it's available offline when staff take their laptops home. Therefore emptying the Start Menu on logoff isn't an option for staff.

[enjay]

I'd be interested to a solution for this as well.

 

We have redirected Start Menus so staff and pupils get different menus, and that has been fine up until now - yes, it means that people get shortcuts to apps which aren't installed, but they learn to cope with that and remember which PCs do and don't have SIMS on them. The problem is now that we're starting to use 64-bit computers too, I'm needing two sets of shortcuts for everything, and that is going to confuse. Redirected menus for 32-bit and 64-bit menus aren't an option, as people will be using both architectures.

[sted]

havnt rear the entire thread so forgive me if someones suggested it and its just thinking out loud

 

could you redirect your startmenu to say c:\startmenu use gpp to populate it by copying from C:\ProgramData\Microsoft\Windows\Start Menu\Programs\whatever that way the shortcut wouldnt get created in the c:\startmenu if that pc diddnt have that piece of software then a logoff script that deletes the folders contents ready for the next user.

[AlexB]

I'd be interested to a solution for this as well.

 

We have redirected Start Menus so staff and pupils get different menus, and that has been fine up until now - yes, it means that people get shortcuts to apps which aren't installed, but they learn to cope with that and remember which PCs do and don't have SIMS on them. The problem is now that we're starting to use 64-bit computers too, I'm needing two sets of shortcuts for everything, and that is going to confuse. Redirected menus for 32-bit and 64-bit menus aren't an option, as people will be using both architectures.

 

See above, locally stored per machine with symbolic link to appdata startmenu would target this.

[TechMonkey]

That's the theory I am going to work on.

 

On a server - StaffStart folder and StudentStart folder full of shortcuts that could potentially be in the start menus (this may get amalgamated into one.)

 

Locally - StaffStart & StudentStart folders on C:\ that a gpp will copy the shortcuts into if the target exists.

 

GPO - will redirect the start menu to the correct folder dependant on user.

 

This way it shouldn't matter if the machine is 64 or 32 bit, if the program exists and a rule has been created the user will get the programs that are available on that machine. Not quite as automated as I would like, someone will still have to copy the shortcuts into the server share and create the GPP rule, but better than nothing. My only worry would be do I bother with grouping shortcuts into folders and have to manage them too and if you get too many GPPs will logon or boot be slow.