Creating Shortcuts for 32 and 64 bit computers

[snagrat]

I create a GPO to set a variable on machines of %ProgramFiles% to C:\Program Files (x86) then in the shortcuts point them to %ProgramFiles%\dir\.exe

 

On a 64bit machines the GPO variable does not overwrite that on the machine so %ProgramFiles% still point to C:\Program Files.

 

Seems to work even though on theory it shouldn't!

 

So the same icon works on both machines.

[rich_tech]

Its something we are in the midst at on our site at the moment going completely 64 bit, it is a headache especially with things like the start menus, I had considered the start menus redirects and WMI filters, but I have to work out where our LEA are at with our start menu redirections first.

 

Going 64 bit site wide is not without its problems too, the latest I am seeing are issues with our USB to Serial connectors for our machines and their interactive whiteboards, going 64 bit for us means that there are no decent drivers or support for these cables so I have had to revert some machines back to the stable 32 bit win 7 atm until we can look at ordering better alternatives as the supposed stable drivers either dont work with 64 bit, or cause multiple crashes and blue screens (their a necessary evil the cables for us seeing as our machines from a certain "rock" supplier, dont have serial ports on them).

[Jamo]

At some point though, 128Bit or more will start becoming the norm, so you'll then have:

 

C:\Program Files

C:\Program Files (x86)

C:\Program Files (x64)

 

Program Files would be renamed again for 64Bit processes.

 

If they did what I suggested, it would be consistent across all versions of Windows concerned. Program Files wouldn't need to be renamed either!

 

C:\Program Files

C:\Program Files (x64)

C:\Program Files (x128)

C:\Program Files (x256) etc..

 

Lol 256 bit Windows for those who need 2^256-1 RAM

 

I would honestly hope that MS have dropped 32bit support by then!

 

Where I work we are entirely x64, no ill effects, although I no longer work in a school so don't have to see the 16bit wonders from SEN anymore!

[witch]

Oh? Primary here with same number of machines here and all but a couple are 64 bit. What's the issue with moving to 64 bit?

 

No issue other than the fact that most of my computers are a good couple of years off replacement - when I am sure they will be 64 bit - but it will be a way down the line.

 

I did ask for a simple solution - not getting it really.

So far if I create two shortcuts - one pointing at Program Files and one at Program Files (x86) it does seem to work. Which seems a bit simple given all the stuff you have all been saying...

[snagrat]

I create a GPO to set a variable on machines of %ProgramFiles% to C:\Program Files (x86) then in the shortcuts point them to %ProgramFiles%\dir\.exe

 

On a 64bit machines the GPO variable does not overwrite that on the machine so %ProgramFiles% still point to C:\Program Files.

 

Seems to work even though on theory it shouldn't!

 

So the same icon works on both machines.

 

I got his wrong as it was late.

 

Create a GPO that sets an Windows Environment of programfiles(x86) and value C:\Program Files.

 

Then point shortcuts to %programfiles(x86)%\dir\.exe

 

Give it ago. Once setup it just works.

 

Thanks

Andrew

[Duke5A]

You're old!

 

I use a modified* version of @jklight's PowerShell script to do our Start Menu. Copying shortcuts into a folder is far easier than having to modify a script each time you want to add another program. Since the script automatically deletes shortcuts that do not exist, you could put both 32-bit and 64-bit shortcuts in the same folder (although obviously they can't have the same name).

 

Btw, wouldn't your script set "strProgramFilesPath" to the wrong location if it was run on a PC with a 64-bit processor and a 32-bit OS? Surely you should be checking the OS architecture rather than the processor architecture?

 

If GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth = 64 Then
strProgramFilesPath = "C:\Program Files (x86)"
Else
strProgramFilesPath = "C:\Program Files"
End If

 

* The script I am using is different from the one posted in the linked thread. It has several improvements like removing empty folders that do not contain any shortcuts and uses the existing Start Menu folder rather than create a new one.

 

...and apparently a little senile too, good catch!

 

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

strAllDesktopPath = WshShell.SpecialFolders("AllUsersDesktop")
strUserDesktopPath = WshShell.SpecialFolders("Desktop")


Set objWMIService = GetObject("winmgmts:\\.\root\CIMV2")
Set colItems = objWMIService.ExecQuery("SELECT * FROM Win32_OperatingSystem", "WQL", wbemFlagReturnImmediately + wbemFlagForwardOnly)

For Each objItem in colItems
If InStr(objItem.OSArchitecture, "64") Then
	strProgramFilesPath = "C:\Program Files (x86)"
Else
	strProgramFilesPath = "C:\Program Files"
End If
Next

On Error Resume Next

If objFSO.FileExists(strUserDesktopPath & "\My Shortcut.lnk") Then
Else
Set objShortcutUrl = WshShell.CreateShortcut(strUserDesktopPath & "\My Shortcut.lnk")
objShortcutUrl.TargetPath = strProgramFilesPath & "\" & "My Program" & "\" & "Program.exe"
objShortcutUrl.WorkingDirectory = strProgramFilesPath & "\" & "My Program"
objShortcutUrl.IconLocation = strProgramFilesPath & "\" & "My Program" & "\" & "Program.exe,0"
objShortcutUrl.Save
End If

 

Our logon script is VB and has been since the days of Win2k; if I was starting over it would most certainly be Power Shell. The way it sits now it handles drive mappings, printer load outs, icon creation, quick fixes, etc. I've become addicted to the granular control scripting has over using GPP. The initialization sub in the logon script pulls username, computer name, user group membership, and LDAP paths for both users and computers.

[witch]

None of that helps me - far too complicated - I feel like someone who thought they were going to play a scale but were expected to play a symphony!

I don't have a logon script anymore. I know nothing about Power Shell

[Boredguy]

You say you have redirection for shortcuts, where are they being redirected to?

If it is to a network location, you could have two different folders, one for 32 bit and one for 64 bit, and use the Group Policy Folder Redirection to direct the start menu based on group membership of the computer the user is on.

 

Having two folders is about as simple as I can think of, which is what we do here, but we use a PowerShell script at start-up that tells the computer to go off to our central repository and copy down only the shortcuts that are available on the computer.

[madurham]

None of that helps me - far too complicated - I feel like someone who thought they were going to play a scale but were expected to play a symphony!

I don't have a logon script anymore. I know nothing about Power Shell

 

I've never done this myself so someone may be able to correct me and it may also not work with your set up.

 

You may be able to have your two shortcuts then create two GPP shorcut rules that delete the shortcut for the opposite architecture, leaving a cleaner Start menu.

Use Item level targeting under the common tab and check for the environment variables of Program files and Program Files(x86).

 

So for example one GPP rule would check if Program Files(x86) exists, if it does it means it's a 64-bit machine and the 32-bit shortcut can be deleted. The other GPP rule would check if Program Files(x86) doesn't exist then delete the 64-bit shortcut.

 

You could also use it to add the relevent shortcut if you can't delete the shorcut e.g. folder redirection.

 

 

Here's the TechNet page on Item Level Targetting

Preference Item-Level Targeting

 

Just found a thread that looks like what you are looking for

Deploying desktop shortcuts via GP for 32-bit programs on 64-bit O/S - Spiceworks

Edited April 4, 2014 by madurham

[FN-GM]

You say you have redirection for shortcuts, where are they being redirected to?

If it is to a network location, you could have two different folders, one for 32 bit and one for 64 bit, and use the Group Policy Folder Redirection to direct the start menu based on group membership of the computer the user is on.

 

Having two folders is about as simple as I can think of, which is what we do here, but we use a PowerShell script at start-up that tells the computer to go off to our central repository and copy down only the shortcuts that are available on the computer.

 

 

Use a WMI filter so you don't need to mess about with groups. We store our redirected folders on the local machines.

[AlexB]

I'm afraid I'd go really simple...

 

the variables %programfiles% and %programfiles(x86)% aren't useful, but if you create a new one, e.g. %programfiles32bit% (which I strongly feel should be part of the OS defaults) and set it to c:\program files on 32 bit machines and c:\program files (x86) on 64 bit machines and just have your shortcuts use %programfilesbit%

 

(This could also be done by adding %programfiles(x86)% to 32 bits machines)

Edited April 4, 2014 by AlexB

[witch]

. and set it to c:\program files on 32 bit machines and c:\program files (x86) on 64 bit machines

(This could also be done by adding %programfiles(x86)% to 32 bits machines)

 

Sorry, what do you mean by "set it" in this context?

[Ephelyon]

I think @DrCheese's solution is the right one. It's what we use here too.

 

You can put this in a startup script for all workstations:

 

@wmic os get osarchitecture | find "32" && if not exist "C:\Program Files (x86)" mklink /j "C:\Program Files (x86)" "C:\Program Files"

 

Then you can have a single redirected Start Menu with shortcuts that only point to the (x86) version of everything... assuming you have no specifically 64-bit software to link to, that is.

Edited April 4, 2014 by Ephelyon

[snagrat]

 

Create a GPO that sets an Windows Environment of programfiles(x86) and value C:\Program Files.

 

Then point shortcuts to %programfiles(x86)%\dir\.exe

 

Give it ago. Once setup it just works.

 

 

Have you tried this? I do it at all my schools just in case different bit systems are introduced and it works.

[AlexB]

Sorry, what do you mean by "set it" in this context?

 

GPO

Computer->Preferences->Windows Settings->Environment

New environment variable

System variable

Name: programfiles(x86)

Value: C:\Program Files

 

Set GPO with a 32bit Architecture filter

[Garacesh]

GPO

Computer->Preferences->Windows Settings->Environment

New environment variable

System variable

Name: programfiles(x86)

Value: C:\Program Files

 

Set GPO with a 32bit Architecture filter

 

Sorry to necrobump, but we're having the same issue with SIMS here, we're exploring transitioning to x64 Windows instead of x86 as there's not an amazing amount of reasons not to if we can do it (truth be told, there's no real reason for x64 and x86 apps to have their own folders either, but anyway...)

 

The %ProgramFiles(x86)% environment variable isn't created for 32 bit systems, but does automatically exist for 64bit systems. With that in mind, would creating a %programfiles(x86)% variable via GPO not interfere with the 'proper' %programfiles(x86)% variable on the 64bit systems? A hard-coded %programfiles(x86%) == "C:\Program Files" would make the shortcuts fail on x64 systems, no? As they'd be wanting to run C:\Program Files (x86) but would be redirected to C:\Program Files?

[sted]

Sorry to necrobump, but we're having the same issue with SIMS here, we're exploring transitioning to x64 Windows instead of x86 as there's not an amazing amount of reasons not to if we can do it (truth be told, there's no real reason for x64 and x86 apps to have their own folders either, but anyway...)

 

The %ProgramFiles(x86)% environment variable isn't created for 32 bit systems, but does automatically exist for 64bit systems. With that in mind, would creating a %programfiles(x86)% variable via GPO not interfere with the 'proper' %programfiles(x86)% variable on the 64bit systems? A hard-coded %programfiles(x86%) == "C:\Program Files" would make the shortcuts fail on x64 systems, no? As they'd be wanting to run C:\Program Files (x86) but would be redirected to C:\Program Files?

 

just wmi filter your script/gpp so that it wont run on x64 systems then it wont even try to add the variable to them

[snagrat]

It doesn't seem to overwrite any built in ones so works fine for me.

 

Try it in a test OU

[Ephelyon]

You can use GPP targeting for e.g. "Windows 7 Enterprise" or "Windows 7 Enterprise 64-bit" if you create the variable that way.

[Joanne]

What I did when I had a mixed environment was create a 32-bit OU in Active Directory and a 64-bit OU in active directory. In hindsight I should have used security groups... so create a 32bit security group and a 64 bit security group. Add the relevant machines to each group.

 

Create a shared folder with all the shortcuts in.

 

In group policy, create a GPO called 32bit shortcuts. Then, in Computer Configuration | Preferences | Windows Settings | Files, set each of the shortcuts for the 32bit machines to copy to the C:\users\public\desktop\ folder (remembering to put the file name and extension onto the end of that). Apply this to the computers OU and on the Scope settings of the GPO, remove all security groups and add the 32 bit machines security group.

 

That will copy the files directly to the machine. Do the same for the 64 bit ones.

 

DOWNSIDES: remembering to add machines to the security groups. All users see the shortcuts you copy (you might not want this).

[Garacesh]

Realistically our environment isn't going to be 'mixed' permanently. If we do push on with x64 we'll likely image computers as-and-when they break, and then do the rest over the holidays.

 

I don't have a tonne of group policy experience, I've only really faffed about with VMs so I'm just collecting ideas to pass upwards at the moment