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.
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?
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?
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.
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?
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 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.
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\<some folder> and if it doesn't exist it creates a symbolic link to where the shortcuts are hidden away. e.g.
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.Code:if not exist "%appdata%\Microsoft\Windows\Start Menu\Programs\<some folder>" if exist "c:\startmenus\<some folder>" linkd.exe "%appdata%\Microsoft\Windows\Start Menu\Programs\<some folder>" "c:\startmenus\<some folder>"
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.
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.
deano (17th May 2012)
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.
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.
There are currently 1 users browsing this thread. (0 members and 1 guests)