Welcome to the second installment of the Road to SharePoint 2010 series. I will tackle the oldest news for this SharePoint version: it will be released only as a 64-bit installation. So, how do we prepare for this requirement? Well, by getting ready with our shiny new 64-bit servers and virtual machines.
(check the original scan from a 1983 magazine here)
The hardware and software requirements were outlined on the official SharePoint team blog.
Which hardware it will need?
64-bit hardware has been recommended for SharePoint 2007 for some time. Testing data shows that SharePoint hugely benefit from improved memory management in 64-bit environment. SQL Server is also memory-intensive application, so it will be grateful for the extended memory space. Roughly, the database will benefit the most, following by the front-end web servers, and the application servers will benefit the least.
Which Windows it will need?
SharePoint 2010 will run on Windows Server 2008 / 2008 R2 x64.
Which SQL Server it will need?
SharePoint will need SQL Server 2005 or 2008 / 2008 R2 x64.
What for the developer Virtual Machines?
You are strongly recommended to have a 64-bit host OS for 64-bit virtual machines, although you still can run a 64-bit VM in a 32-bit host OS. If you are using 32-bit OS for the host, you must have a 64-bit capable processor (check here) and activate the 64-bit virtual extensions in the BIOS (called Intel VT or AMD-V, depending on the CPU maker).
Do I have to worry about my custom .NET code in SharePoint? How can I port it to 64-bits?
You will have to recompile your source code in 64 bits configuration (or in AnyCPU build configuration). The 64-bit NET cannot load a 32-bit-only assembly.
If you don’t have the source code, as with IFilters or third-party extensions, you will have to obtain the 64-bit version, if available. If not, you will have to remove that component from the farm.
As for the NET Framework in 64 bits, there are useful references at MSDN to help us migrate our existing code. In short, if you stick to the managed code, you shouldn’t have problems. The problems arise when you use platform-dependent (alias P-Invoke) operations that cross the managed code boundaries and access the Windows directly. There’s a known issue with int data type pointers coming from COM or P-Invoke layer, you should use IntPtr data type instead.
If you want the gory details of the 32-to-64-bits issues, Scott Hanselman has a nice blog entry about it.
How to migrate my SharePoint farm from 32 to 64 bits?
The best way is to do it gradually.First you move the database tier, then the application servers and finally the web servers, as illustrated on this figure. Do not mix 32 and 64 bit servers on the same tier.
The recommended steps are outlined in this TechNet article: http://technet.microsoft.com/en-us/library/dd622865.aspx