April 29 2011

Reasons to avoid Windows 7 32-bit



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

There is a great new post over here (http://adventuresinosd.blogspot.com/2011/04/top-10-reasons-to-avoid-windows-7-32.html) at Adventures in OSD on the reasons to avoid the 32-bit version of Windows 7 in the enterprise.

I strongly agree with all of his points and made one conclusion – if you are going to run a 32-bit OS then stick with Windows XP 32-bit, if you are going to run a 64-bit OS then run Windows 7 64-bit. Don’t give any other options.

I have deployed both 32 and 64 bit versions of Windows 7 in environments too and you are basically creating yourself twice the work with a nightmare of ongoing maintenance.

More here – http://adventuresinosd.blogspot.com/2011/04/top-10-reasons-to-avoid-windows-7-32.html



----------------------------------------------------------------------------
I use a maximum of one Google Ad per post to help offset some of my blog hosting costs.

----------------------------------------------------------------------------

April 21 2010

Considerations when scripting for 64-bit machines with SCCM

As Microsoft 64-bit client Operating Systems become more common, we need to ensure we are covering all combinations when scripting in general as well as within SCCM programs. I wanted to highlight a recent situation where I couldn’t figure out why my script couldn’t write to the %systemroot%System32 folder on a 64 bit Windows 7 workstation. Then it clicked – whenever a 32-bit application attempts to access %windir%System32, the access is redirected to %windir%SysWOW64 – and don’t forget – the SCCM client is 32-bit!

32-bit applications can access the native system directory by substituting %windir%Sysnative for %windir%System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access.

There are some good references here, here and here.

As a separate but related topic, I think it’s worthwhile pointing out this relatively new post at MyITForum that relates to UNC paths within batch files. Most people will tell you that UNC paths are not supported in a batch file – well that isn’t necessarily the case – “%~dp0” is a variable that can be used in your batch file that will give you the full UNC path of where your script is being run from. From more info, see this post http://www.myitforum.com/absolutenm/templates/Articles.aspx?articleid=15520&zoneid=87
 
 

March 27 2010

Simple query to find if processor is 64 bit capable

I’ve often used a very simple query to find if a processor is 64 bit capable. Open up a command prompt and enter the following:
wmic cpu get datawidth
I doesn’t matter the version of the Operating System you are running, this WMI query will return the actually hardware processor capability. If it returns a value of 64, this means that the hardware is 64-bit capable, so you can go ahead and load up a 64-bit version of the OS. If the value is returned as 32 then unfortunately your hardware is only 32-bit capable and you are stuck with the 32-bit version of the OS.

February 2 2010

ODBC settings on 64-bit servers

With more clients and servers going 64bit, if you are troubleshooting ODBC issues on Clients or Servers running 64-bit operating systems (especially with 32bit apps) then you may need to check the 32bit version of ODBC Data Source Administrator to see the appropriate DSNs:
According to Microsoft ( http://support.microsoft.com/kb/942976/en-us ):
The 32-bit version of the ODBC Administrator tool displays 32-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs. The 64-bit version of the ODBC Administrator tool displays 64-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs.
Admin tools/Data Sources(ODBC) by default shows the 64-bit edition, run the 32-bit edition from here: C:WindowsSysWOW64odbcad32.exe
(The 64-bit ed is here: C:WindowsSystem32odbcad32.exe – I guess odbcad64.exe was too hard?) – You must close any open ODBC admin windows first, otherwise you won’t see any changes.

If you are troubleshooting ODBC issues on machines running 64-bit operating systems (especially with 32bit apps) then you may need to check the 32bit version of ODBC Data Source Administrator.

The 32-bit version of the ODBC Administrator tool displays 32-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs. The 64-bit version of the ODBC Administrator tool displays 64-bit system DSNs, 32-bit user DSNs, and 64-bit user DSNs.

Administrative tools –> Data Sources(ODBC) by default shows the 64-bit edition, run the 32-bit edition from C:WindowsSysWOW64odbcad32.exe

The 64-bit edition is located at C:WindowsSystem32odbcad32.exe – indeed a very confusing file naming convention – you must close any open ODBC admin windows first, otherwise you won’t see any changes.

More information from Microsoft –> http://support.microsoft.com/kb/942976/en-us