Windows Server 2003 Terminal Server Licensing notes

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.

Build-In

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

-Eric

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

• 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.

-Eric

Windows Server 2003 (R2) Active Directory Infrastructure Best Practices

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.

-Eric

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

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.

-Eric