SQL Server 2005 features that are dependent on Windows Server 2003…

 The question about what features are supported by SQL Server 2005 running on Windows Server 2003 comes up quite often. So below are some of the features that are depends on the OS and brief description about them.

1. Password policy/expiration check for SQL logins - CREATE LOGIN is a new DDL for creating SQL logins. It has two options called CHECK_POLICY and CHECK_EXPIRATION that can be used to enforce Windows password policies for SQL logins. This leverages the functionality provided by NetValidatePasswordPolicy() API

2. Hot add memory - This is a new feature in Windows Server 2003 that can help SQL Server 2005 indirectly
3. Dynamic AWE - SQK Server 2005 running on Windows Server 2003 uses dynamic AWE memory allocation. This works similar to regular memory management

4. 64-bit versions of SQL Server 2005 runs only on Windows Server 2003 64-bit (IA and X64) - Native 64-bit editions of SQL Server 2005 runs only on corresponding Windows Server 2003 64-bit editions

5. SOAP support - Native XML web services in SQL Server 2005 relies on HTTP API support which is provided by Windows Server 2003 and Windows XP Service Pack 2

6. Fast file initialization - Creating a new database of any size is almost instantaneous in SQL Server 2005 running on Windows Server 2003/XP. This requires the service account to have the SE_MANAGE_VOLUME_NAME permissions. With fast file initialization, disk content is overwritten when new allocation happens

7. SQL Writer service features that work with Volume Shadow Copy Services - Differential backup, differential restore, restore with move, database rename, copy only backup and auto-recovered Snapshots are supported only on Windows Server 2003 with Service Pack 1

 In addition to these features that can benefit SQL Server installations on Windows Server 2003 platform, there are other inherent advantages. Windows Server 2003 is more scalaeable and secure than Windows Server 2000. These are just some of the things to keep in mind when choosing a platform for running SQL Server 2005. The link below contains some benefits on using Windows Server 2003 with SQL Server 2005:



Comments (10)

  1. safi says:

    What does it mean "Hot add memory"?

  2. sqletips says:

    Windows Server 2003 has a feature that allows memory modules to be added while the operating system is running. This requires special hardware. You may want to check the hardware compatibility list for Windows Servers to see the supported machines. Check the link below:



  3. Cristian Lefter, SQL Server MVP says:

    AFAIK – Native HTTP support is available also in Windows XP.

  4. sqletips says:

    Thanks for the clarification. Yes it is available on Windows XP too but only with Service Pack 2. I have updated the post with my comments.

  5. satishch says:

    My company is buying hardware which is 64-bit

    ready (HP DL585). Can we use SQL Server 2005 64-bit on Windows Server 2003 64-bit OS? Is it mature enough to go for 64-bit technology now. We started working on the project and it will be deployed 1 year from now. I was wondering going for 64-bit at this point is a good idea or not. Please advise.

  6. Umachandar Jayachandran says:

    Yes, you can use SQL Server 2005 x64 Edition and Windows Server 2003 x64 Edition. The x64 and EM64T technologies are mature for running critical database applications. You can also take a look at the benchmark results that we have posted on these platforms at http://www.tpc.org.

    For example, depending on your workload the larger virtual address space in the 64-bit platform will help improve performance.


  7. Jesse says:

    Is there a method in SQL 2005 to globally disable the CHECK_POLICY option? I am aware you can disable this check on a single CREATE LOGIN statement.

  8. sqletips says:

    CHECK_POLICY cannot be disabled globally. You will have to do it at the login-level only.


  9. rschaal says:

    I use an ini-file to setup an SQL 2005 Express Edition. Specifying the SAPWD-Parameter with a weak Password breaks the setup because of check_policy.

    Is there a way in SQL 2005 to disable the check_policy for sa during setup?

Skip to main content