Can you create Junction points in a script and push them out to all of the x64 machines?
Be aware the 64bit item level targeting doesnt work on win 7 x64 without a hotfix.
Group Policy preference item-level targeting does not work for 64-bit versions of Windows 7
We have a redirect start menu for each room so we know where the 32bit pcs are.
Call me old, but I still prefer to use VB for this stuff.
I just tossed this together, so it needs to be tested.Code:Set objFSO = CreateObject("Scripting.FileSystemObject") Set WshShell = CreateObject("WScript.Shell") strAllDesktopPath = WshShell.SpecialFolders("AllUsersDesktop") strUserDesktopPath = WshShell.SpecialFolders("Desktop") If GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth = 64 Then strProgramFilesPath = "C:\Program Files (x86)" Else strProgramFilesPath = "C:\Program Files" End If 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
We had 2 redirected start menus when we had a mix. One for x86 and the other for x64. You can separate the group policy that enforces them with a WMI filter.
4 Pebibytes of RAM in a single computer, it would be far easier to buy another computer and network them together.
64-bit versions of Windows have two folders for application files; 'Program Files' folder serves as the default installation target for native (in this case 64-bit) programs, while the 'Program Files (x86)' folder is the default installation target for non-native (in this case x86-32) programs. While 64-bit Windows versions also have a %ProgramFiles(x86)% environment variable, the dirids/CSIDLs are not different for 32-bit/64-bit; the setup/shell APIs merely return different results, depending on whether the calling process is native or not.
To be backwards compatible with the 8.3 limitations of the old File Allocation Table file names, the names 'Program Files', 'Program Files (x86)' and 'Common Program Files' are shortened by the system to progra~N and common~N, where N is a digit, a sequence number that on a clean install will be 1 (or 1 and 2 when both 'Program Files' and 'Program Files (x86)' are present). (Source)
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?
* 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.Code:If GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth = 64 Then strProgramFilesPath = "C:\Program Files (x86)" Else strProgramFilesPath = "C:\Program Files" End If
Duke5A (3rd April 2014)
I cheated and just made a symlink of "Program files (x86)" on our 32bit machines, gets around this easily :P
Still - If Microsoft used Program Files for existing 32Bit processes and Program Files (x64) for new 64Bit processes, even in a mixed environment; because the 32Bit process would be in the same directory on both platforms, it would have made things considerably easier this way.
When (at some point) 128Bit OSes and processes come about, Microsoft would (in theory) rename Program Files again... it's just a bit messy doing it this way.
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.
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).
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...
witch (3rd April 2014)
There are currently 1 users browsing this thread. (0 members and 1 guests)