Do you have IIS on Windows 64 bit and want to run application that is for 32 bit. No problem. From the Inetpub admin scripts run the following:

"cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 true"

Here are the details.

Windows Server 2003^TM, Service Pack 1 enables IIS 6.0 to run 32-bit Web applications on 64-bit Windows using the Windows-32-on-Windows-64 (WOW64) compatibility layer. IIS 6.0 using WOW64 is intended to run 32-bit personal productivity applications needed by software developers and administrators, including 32-bit Internet Information Services (IIS) Web applications.

On 64-bit Windows, 32-bit processes cannot load 64-bit DLLs, and 64-bit processes cannot load 32-bit DLLs. If you plan to run 32-bit applications on 64-bit Windows, you must configure IIS to create 32-bit worker processes. Once you have configured IIS to create 32-bit worker processes, you can run the following types of IIS applications on 64-bit Windows:

• Internet Server API (ISAPI) extensions
• ISAPI filters
• Active Server Page (ASP) applications (specifically, scripts calling COM objects where the COM object can be 32-bit or 64-bit)
• ASP.NET applications

IIS can, by default, launch Common Gateway Interface (CGI) applications on 64-bit Windows, because CGI applications run in a separate process.

Before you configure IIS to run 32-bit applications on 64-bit Windows, note the following:

• IIS only supports 32bit worker processes in Worker Process Isolation mode on 64-bit Windows
• On 64-bit Windows, the World Wide Web Publishing service can run 32-bit and 64-bit worker processes. Other IIS services like the IIS Admin service, the SMTP service, the NNTP service, and the FTP service run 64-bit processes only
• 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

You want to establish an external trust between two domains where there is an ISA 2004 or ISA 2006 in between.  Establishing trust requires Kerberos, LDAP, DNS, CIFS & the big problem is the RPCs… one idea is to strict the RPC port on the DCs using registry and open this specified range on the ISA which will be not less than 100 port per the recommendations, other idea was to create an IPSEC tunnel between both DCs and open the IPSC ports only on the firewall however the cons of this solution is the complexity & the exposure of both DCs communication between each other. With ISA 2004 & 2006 the RPC filter will help you establish this, the filter listens for the RPC port maper 135 request and depending on the UUID the ISA sees which port is required to be opened for such service and dynamically open the port for the communication till the session ends. So based on this great cool feature only the below ports are only required to be opened on the ISA.

PING (ICMP)

DNS Query

Kerberos-Sec (UDP)              88  UDP SEND/RECEIVE

LDAP                                     389 UDP SEND/RECEIVE

LDAP (UDP)                          389 TCP OUTBOUND

Microsoft CIFS (TCP)            445 TCP OUTBOUND

RPC (All interfaces)             135 TCP OUTBOUND

Note: PING is required and don’t forget to establish a name resolution mechanism, I would recommend DNS conditional forwarding for both domains

This article describes changes in Windows operating systems that will support disk logical unit sizes larger than 2 TB.

In past editions, Windows used 32-bit block numbers in the lower storage stack. This effectively limited support for single disk devices-which might be hardware RAID sets, sometimes called virtual disks or LUNs-to being no larger than 2 terabytes (TB). To get storage unit sizes beyond 2 TB, one had to combine multiple LUNs using the Volume Manager, leading to a volume limit of 64 TB with RAID0 or spanning or 62 TB with RAID5. RAID1 was also limited to 2 TB. The use of Volume Manager sets, however, imposes a performance penalty and can make some storage management scenarios difficult or impossible.

In contrast, the file system uses a 64-bit signed byte offset. This means that the absolute file system limit is actually 2⁵⁴ 512-byte blocks. However, NTFS reduces this, because it supports a 32-bit cluster number * 64K per cluster maximum, which equals 256 TB.

Another complicating factor was the use of Master Book Record (MBR) partition types, which can only contain up to 2³² blocks. GUID Partition Tables (GPT) can support a much larger number of blocks, but Windows only supported GPT on Intel Itanium machines.

Note: Microsoft recommends that for Windows Server 2003, basic disks should use 512-byte sectors (dynamic disks will only work with 512-byte sectors). Windows Vista and later operating systems will support up to 4-KB sector sizes.

With Windows Server 2003 Service Pack 1 (SP1) and Windows XP 64-bit Edition (x64), these limits have changed.

Microsoft added support for 64-bit block numbers in the disk/class layer, using the new SCSI Commands included in the SCSI-3 Block Commands-2 command set. Microsoft also enabled GPT support for all Windows Server 2003 SP1 platforms. With this change, for example, a snapshot of a GPT partition on an Itanium-based machine can now be transported to a 32-bit machine for data mining or archiving purposes.

The new limits are as follows:

·         Basic or dynamic volume size: 2⁶⁴ blocks = 2⁷³ bytes (too big to pronounce)

·         Maximum NTFS file system size that can be realized on Windows: 256 TB

Note: Disk devices with more than 2 TB of disk space must be converted to GPT format for all of the disk space to be usable. If the device uses MBR format, the disk space beyond 2 TB will be unusable

If you are interested in AD performance on 64 bit you shoud read this great guide

http://www.microsoft.com/downloads/details.aspx?FamilyID=52E7C3BD-570A-475C-96E0-316DC821E3E7&displaylang=en