Posts Tagged ‘Windows Server 2003 R2’

Windows Server 2003 Terminal Server Licensing notes

October 20, 2009 Leave a comment

In Windows Server 2003 Terminal Server a client access license is issued to every type of client that will access it. Basically it includes Windows Server 2003 client connections Windows XP, Thin clients etc.

There is now two types of licenses: Per User and Per Device. Built-in ones still exist so that Windows Server 2003 Terminal Server Licensing Server supports Windows 2000 Terminal Servers and can issue licenses to them.

Per User

Basically if you selected this mode, it means that in Terminal Server Configuration console the Terminal Sever must be able to discover an activated terminal server license server. As long as its doable, users will never be denied a connection to the terminal server based on licensing and the number of available licenses will not drop.

Per Device

If you selected this mode, it means that if a computer connects to the terminal server, it gets a temporary license. If it connects again, then gets a permanent license. This license only last for 90 days. At some point before it expires license will be renewed. Now if the client doesn’t connect back before the license expires, it will be returned to the pool of licenses and will be available again.


These type of licenses only exist for backward compatibility for Windows 2000 Terminal Servers.



Windows Server 2003 (R2) System Level Fault Tolerance (Clustering/NLB) Best Practices

October 14, 2009 Leave a comment
  • Always use quality server & networking hardware for fault-tolerant systems.
  • Use RAID to create disk subsystem redundancy.
  • Don’t run MSCS and NLB on the same computer, as it’s not supported by Microsoft.
  • When possible, try to use cluster-aware applications, so you can use cluster service to monitor the application. If you use cluster-unaware application, it can run on a cluster, but the application is not monitored by cluster service.
  • Use active/passive clustering mode, when performance is not critical. It is easier to administrate and licensing costs are lower.
  • If you got TCP/IP-based services such as Terminal Services, Web sites, VPN services or streaming media services, use NLB.
  • For mission critical applications (enterprise messaging, databases, file and print services) use Windows Server 2003 Cluster Services to provide server failover functionality.
  • Disable power management on each of the cluster nodes. IN BIOS and in operating system’s control panel to avoid unwanted failovers.
  • Choose carefully whether you should use nonshared or shared disk approcah to clustering.
  • When you plan to use MSN cluster, always purchase 1 additional node.
  • Be sure that MS and software manufacturer certify that 3rd party software for Cluster Service works on Windows Server 2003 cluster or you might be faced with limited support when troubleshooting is needed.
  • In each node use multiple network cards. For example one card can be dedicated to private network (internal cluster communications), other can be used for public network (client connectivity) or both can be used for mixed network (public and private communication)
  • Configure failback schedule to allow failback only during non-peak times or after hours to reduce the chance of having a group failing back to a node during regular business hours after a failure.
  • Test failover and failback mechanism thoroughly.
  • If you are logged in with Cluster Service account, don’t use AD Users & Computers or Windows security box to change the password.
  • If you’re removing a node from MNS cluster, make sure that majority of the nodes remain running to keep the cluster in a working state.
  • Carefully consider how to backup and restore a cluster.
  • Perform ASR backups periodically and immediately after any hardware changes to a cluster node including changes on a shared storage device or local disk configuration.
  • Before deciding which clustering technology to use, make sure you understand the application that will be used thoroughly.
  • Create a rule that allows only specific ports to the clustered IP address and block all others.
  • Use tools like robocopy.exe to replicate data between NLB nodes.


Windows Server 2003 (R2) Active Directory Infrastructure Best Practices

October 11, 2009 Leave a comment

Make sure that schema version has been upgraded to R2 levels before installing Windows Server 2003 R2 on any DC.

Make sure that all sites listed in DNS contain proper SRV (Service) records.

Use automatically generated connection objects, unless a specific reason exists to hard-code replication pathways.

To troubleshoot and validate AD replication use repadmin and replmon.

Don’t turn off site link bridging unless you want to make your DC replication dependent on the explicit site links that your created.


Best Practices of designing a Windows Server 2003 (R2) AD Organisational Unit and Group structure

October 6, 2009 Leave a comment

If you are confused about domain groups, try to remember the following. Use domain local groups to control access to resources, and use global groups to organise similar groups of users.

  • Set up OU structure, and move your user and computer objects from default Users and Computers containers.
  • While designing the OU structure, keep in mind the principle as simple as possible.
  • When designing OU structure, try to keep OUs 3 layers deep, if possible. You can use more layers, if needed, but don’t nest OUs more than 10 layers deep.
  • Use OUs only when necessary, and try to keep their number minimal.
  • Apply Group Policy to members of groups through Group Policy Membership Filtering where possible.
  • Use domain local groups to control access to resources, and use global groups to organize similar groups of users.
  • Use distribution groups or mail-enabled security groups to create email distribution lists in environments with Exchange 2003/2007.
  • Mail-enable security groups if separation of security and email functionality is not required.
  • Don’t delete/re-create groups randomly, because each of them has a unique SID.
  • Don’t include users from other Mixed mode domains in a forest in universal groups.
  • Don’t use local groups for permissions in a domain environment.


Best Practices of designing a Windows Server 2003 (R2) Active Directory

October 5, 2009 Leave a comment
  • Understand completely Active Directory’s structure before designing.
  • Secure external namespaces via registration, so that i can’t be used anywhere on the Internet.
  • Start your domain design by considering the simplest solution/model first (single domain model).
  • Consider using multiple domains only for specific reasons.
  • Consider using federated forest design, when uniting two different Active Directory structures.
  • Use sites to control and optimize replication traffic.
  • Upgrade any down-level clients to reduce administration and maintenance.
  • Use domain rename only when faced with no other alternative.



Windows Server 2003 (R2) Active Directory Best Practices

October 5, 2009 1 comment


  • Purchase any external domain namespaces that in theory could be used and bought on the Internet.
  • Don’t set up multiple domains for different remote (branch) offices or sites. Design domains sparingly.
  • Consider using Dynamic DNS in an Active Directory environment.
  • Consider using cross-forest transitive trusts between two different Active Directory forests when merging them is not an option.
  • Establish as a site to every geographic area that requires fast access to the latest directory information.
  • In every site place at least one domain controller. Also in every site make at least one domain controller a global catalog server.
  • Unless all domain controllers in the domain are global catalog servers or you have a single domain environment, place the infrastructure master role on a domain controller that isn’t also a global catalog.
  • To transfer FSMO roles in disaster recovery situations, use the ntdsutil utility.
  • Use global groups to contain users in the domain in which they exist but also to grant access to resources in other trusted domains.
  • Use universal groups to contain users from any domain in the forest and to grant access to any resource in the forest.
  • Perform regular backups of domain controllers in order to preserve all trust relationships within that domain.


  • Don’t log on to your computer with administrative credentials.
  • Rename or disable the Administrator account (and guest account) in each domain to prevent attacks on your domains.
  • Physically secure all domain controllers in a locked room.
  • Manage the security relationship between two forests and simplify security administration and authentication across forests.
  • To secure AD schema a bit more, remove all users from the Schema Admins group, and add a user to the group only when you need to mate schema changes. Once done, remove the added user from the group again.
  • Restrict user, group, and computer access to shared resources and to filter Group Policy settings.
  • Avoid disabling the use of signed or encrypted LDAP traffic for Active Directory administrative tools.
  • Some default user rights assigned to specific default groups may allow members of those groups to gain additional rights in the domain, including administrative rights. Therefore, your organisation must equally trust all personnel that are members of the Enterprise Admins, Domain Admins, Account Operators, Server Operators, Print Operators and Backup Operators groups.
  • Use global groups or universal groups instead of domain local groups when specifying permissions on domain directory objects replicated to the global catalog.



How to move DHCP db from Windows Server 2003 to Windows Server 2008

September 1, 2009 Leave a comment

On your Windows 2003 Server go Start-> run and type cmd.

Here’s the command to export your db:

netsh dhcp server export C:\dhcpdb.txt all

and press ENTER

On your Windows 2008 server go Start and type cmd right click on it and select Run as Administrator.

Here’s the command to import your db:

netsh dhcp server import C:\dhcpdb.txt all

and press ENTER

Bare in mind that C:\dhcpdb.txt is full path and file name of the database file that you copied to the server.

More information could be find out from this blog.