There are a few very important things you need to be aware of when choosing between 32-bit and 64-bit MOSS environments.
Upgrade and migration
.Net 1.1 framework is not installed on Windows Server 2003 64-bit by default. You can download and install it, but here's the issue: to run .Net 1.1 code in IIS, you have to set IIS to run in 32-bit mode. This is a global server setting and by doing this, you are also running MOSS in 32-bit mode, losing any benefits of a 64-bit installation. In other words, you might as well have gone 32-bit in the first place. Here is the Microsoft support article on how to configure IIS for .Net 1.1 on Windows 2003 64-bit.
Why is this an issue? Chances are, you have an investment in third-party or custom-developed .Net 1.1 SharePoint 2003 customizations such as web parts and controls. Be prepared to build extra time into your migration schedule to update these to .Net 2.0. In many cases, this is the desirable path and the right time to do it is during upgrade. The downside is that you are potentially de-stabilizing solutions and customers won't see a big return in terms of functionality for this investment. But if the customer wants to run 64-bit, then the investment is necessary.
Indexing and IFilters
Not all IFilters are available in a 64-bit version. In fact, at the time of this posting, the PDF IFilter is not available from Adobe. You can get a 64-bit from a Foxit software here. If necessary, you can make your index server 32-bit until 64-bit IFilters are widely available. You can mix 32-bit and 64-bit MOSS servers in the same farm, by the way.
Hardware drivers
The technicians building the servers need to ensure 64-bit drivers are available for the hardware and that they use them!
Application integration
Applications that co-exist with SharePoint may be dependent on .Net 1.1. A good example is Business Scorecard Manager. Check out this article on that subject.
Experiencing isues that are specific to 64-bit environments
You may find as I have errors that are specific to 64-bit environments. Because 64-bit is relatively new in terms of adoption, you may also find it more difficult to find solutions. I'm not saying that Microsoft won't support you, but I am saying you will find less information from blogs and forums which are often very helpful for problem solving. A great example of this is the following error which I have been unable to resolve and exists on 2 different 64-bit farms. The symptoms go like this: you are unable to open IIS Manager on the server. iisreset will fix the issue. The event log is filling up with variations of the following error message:
Attempted to read or write protected memory. This is often an indication that other memory is corrupt.
By the way, if anyone has the solution to that problem, please let me know!
Do the benefits outweigh the gotchas?
64-bit architectures are more scalable and performant. 64-bit servers can have more physical memory and CPUs as well as increased virtual memory capabilities. Consider this example from Microsoft:
The application, which had been running on a dual processor, 32-bit server was moved to a new four-way, x64 server with 32 GB of RAM running Windows Server 2003 x64 Edition and a beta x64 version of SQL Server 2005. The historical query, which had taken 8 hours to finish on 32-bit Windows and SQL Server, now finishes in less than 5 minutes.
If you are interested in learning more about the benefits of 64-bit Windows, check out this whitepaper from Microsoft.
Summary
Be aware of the "gotchas" with a 64-bit MOSS farm when determining if 64-bit is the right path for your (or your customer's) environment.
I have a question: We have a small SharePoint Farm with two Web Front End Servers (64 Bit Server 2003). 64 Bit SharePoint was running fine. Then in order to run a 32 bit Web Page we performed following steps (essentially allowed the 32 bit webpage to run by setting ecanble32bitapponwin64 to true). This made our 64 Bit to stop working completely on this web front end server. We could not open even the SharePoint Central Administration. The problem has been resolved by reversing the steps and repairing SharePoint, but is this something expected?
–
Windows, you need to configure IIS to run 32-bit applications.
1. Open a command prompt and navigate to the %systemdrive%InetpubAdminScripts directory.
2. Type the following command:
cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true 3. Press Enter.
Note: For full details, see the Microsoft article Running 32-bit Applications on 64-bit Windows (http://technet2.microsoft.com/WindowsServer/en/library/ee52acd2-
84e0-417c-92b3-80b1cb3848281033.mspx?mfr=true).
4. Install ASP.Net (32-bit version) by typing the following in the command window:
C:WINDOWSMicrosoft.NETFramework2.0.50727>aspnet_regiis.exe -i 5. Type iisreset at a command prompt.
6. In the IIS Management console, under Web Service Extensions, allow ASP.NET (32-bit).
According to:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/13f991a5-45eb-496c-8618-2179c3753bb0.mspx?mfr=true
>On 64-bit Windows, the World Wide Web Publishing service does not support running 32-bit and 64-bit worker processes concurrently on the same server.
So, it seems that a 64 bit SharePoint would be unable to load after the Enable32BitAppOnWin64 has been set to true since it spawns a 32 bit worker process (W3WP), which can no longer load 64 Bit SharePoint bits anymore. This is our understanding at the moment with IIS 6 at least (this seems to be a global setting and thus a show stopper).
One could run a 32 bit SharePoint or alternatively run the 32 bit applications somewhere else: on a different machine since 64 bit SharePoint is much more powerful and it may not be worth giving it up just for the sake of running some other 32 bit process.