How to Seize FSMO roles on Windows 2003 Server Environment

To seize the FSMO roles by using Ntdsutil, follow the below steps:

1. On the domain controller, click StartRun and type Ntdsutil in the Open box, and then click OK.


2. Type roles, and then press ENTER.


Note: To see a list of available commands at any of the prompts in the Ntdsutil tool, type ? and then press


3. Type connections and then press ENTER.


4. Type connect to server <GDCPORTAL>, where <GDCPORTAL> is the name of the server you want to use, and then press ENTER.


5. At the server connections: prompt, type q, and then press ENTER again.


6. Type seize <role>, where <role> is the role you want to seize. For example, to seize the RID Master role, you would type seize rid master:

Options are:


7. You will receive a warning window asking if you want to perform the seize. Click on Yes

. clip_image013


Note: All five roles need to be in the forest. If the first domain controller is out of the forest then seize all roles. Determine which roles are to be on which remaining domain controllers so that all five roles are not on only one server.

· Repeat steps 6 and 7 until you've seized all the required FSMO roles.

· After you seize or transfer the roles, type q, and then press ENTER until you quit the Ntdsutil tool.

Note: Do not put the Infrastructure Master (IM) role on the same domain controller as the Global Catalog server. If the Infrastructure Master runs on a GC server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest.

Difference between IPv4 and IPv6



Addresses are 32 bits (4 bytes) in length.

Addresses are 128 bits (16 bytes) in length

Address (A) resource records in DNS to map host names to IPv4 addresses.

Address (AAAA) resource records in DNS to map host names to IPv6 addresses.

Pointer (PTR) resource records in the IN-ADDR.ARPA DNS domain to map IPv4 addresses to host names.

Pointer (PTR) resource records in the IP6.ARPA DNS domain to map IPv6 addresses to host names.

IPSec is optional and should be supported externally

IPSec support is not optional

Header does not identify packet flow for QoS handling by routers

Header contains Flow Label field, which Identifies packet flow for QoS handling by router.

Both routers and the sending host fragment packets.

Routers do not support packet fragmentation. Sending host fragments packets

Header includes a checksum.

Header does not include a checksum.

Header includes options.

Optional data is supported as extension headers.

ARP uses broadcast ARP request to resolve IP to MAC/Hardware address.

Multicast Neighbor Solicitation messages resolve IP addresses to MAC addresses.

Internet Group Management Protocol (IGMP) manages membership in local subnet groups.

Multicast Listener Discovery (MLD) messages manage membership in local subnet groups.

Broadcast addresses are used to send traffic to all nodes on a subnet.

IPv6 uses a link-local scope all-nodes multicast address.

Configured either manually or through DHCP.

Does not require manual configuration or DHCP.

Must support a 576-byte packet size (possibly fragmented).

Must support a 1280-byte packet size (without fragmentation).

Useful Symantec links for troubleshoot client communication issue

Troubleshooting communication problems with Symantec Client Security 3.x or Symantec AntiVirus Corporate Edition 10.x

Symantec AntiVirus quick communications check

Activating Windows 2003 Terminal server license on end user system

Many of us face challenges while we activate the terminal servers licenses from the remote system. Recently I faced the same issue and I followed the below steps and the problem was resolved.

  1. The Terminal Services Licensing Server must be configured properly and it must be up and running fine on the same network environment. For example, we will consider this server Frank2k3 ( as a Terminal services licensing server and this server is reachable to the End user system.
  2. If the Terminal Services Licensing Server is present in a different network then we have to enable the required communication ports between two environments. For example if we have the Licensing server present in the network 192.168.150.X and the End user system present in the network 10.50.10.X then we need to enable the following ports from the End user network (10.150.10.X) to the 192.168.150.X network: TCP-135, TCP-139, TCP-445, TCP 5000-5100**.

     (The ports range of 5000-5100 can be modified to any other range of at least 100 ports and it should be above the port 1024.  I used 5000-5100).

  3. We need to add below entries in the registry (use regedit.exe tool and update the registry). Create the Key in the name of Internet under KEY_LOCAL_MACHINE\Software\Microsoft\Rpc

      Under the Internet key, add the below three values
      ”Ports” (MULTI_SZ)
      ”PortsInternetAvailable” (REG_SZ)
      ”UseInternetPorts” (REG_SZ)

  4. After update of the above entry in the End user system the new registry key appears as follows:
      Ports: REG_MULTI_SZ: 5000-5100
      PortsInternetAvailable: REG_SZ: Y
      UseInternetPorts: REG_SZ: Y
  5. Restart End user system. All applications that use RPC dynamic port allocation use ports 5000 through 5100, inclusive. In most environments, a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.
  6. On the End user system, open up Terminal Services Configuration.  Click on Server Settings --> License server discovery mode and fill in the IP address of the Terminal Server Licensing Server (  Clicking on the Check Names button should tell you if it is working or not.  Finally click on Server Settings –> Licensing and select Per Device or Per User, to match whatever types of licenses are installed on the licensing server.  We used the Per Device license.  Everything will work now.  If any problem occurs, then check the Licensing server and it will show up in the System event log with event ID 1010.
  7. The end user system (10.50.10.X) will need to be rebooted after these changes.

The below screen shots show the registry changes:



Avoiding performance issues with Linked Clone VMware View Desktop through fully deployed (thick) desktop

              Optimal design of a VMware View environment must take several factors into consideration. One of the most important factor is the Storage design. When proper storage design planning is not done, it invariably leads to performance issues in the environment. The most prominent example would be having linked clones in an environment in multiple SATA drives with very little cache space. There is a solution for avoiding such performance issues and that is to have fully deployed (thick disk) desktop. Having fully deployed desktops means spreading the I/O over many spindles instead of crowding all requests to one spindle.

This can be done in two methods:

  • Cloning the Desktop VM
  • Storage VMotion the Desktop VM

Cloning the Desktop VM


  1. From VCenter, right click on desktop VM. Select ‘Clone’

  2. Keeping continuing with the wizard till the point of selecting what to do with the disk

  3. Now select ‘Same Format as Source’

These steps can be done when the desktop is on or off (hot or cold). In a nutshell, the linked clone is read (the latest snapshot of vmdk file that includes all changes down to base disk) and  stand-alone disks are created which are independent of the linked clone storage structure. Thus the file created from the cloning is the thick vmdk file which can now be used as base.

The advantage with this method is that one can verify that the cloning is complete before removing the linked clone VM in the View Manager. The new one can be manually added after verification.

Storage VMotion the Desktop VM


  1. From VCenter, right click on Desktop VM. Select ‘Migrate’

  2. Select ‘Change Datastore’

  3. Follow the next steps and select ‘Same Format as Source’ in disk section

The VMs are converted just in the same way as the first method with the only benefit that this can be done without any downtime for the desktop.

This method also has the disadvantage of having no verification mechanism and the necessity of free space to be available on another datastore.

Tips for strong password in server hardening

The need for a highly secure Strong Password is felt more these days due to increased hacking and phishing. With Microsoft integrating windows logon to many online transactions, the need is further more important.

The password policy setting is one of the most important steps in server hardening procedure. This is usually done in 99% of the environments. But if in any environment it was overlooked, there are methods how one can enforce the strong password policy there.

The steps to enable password security policy in Windows 2003 Domain server is presented in this post:

Step#1: Start—> Program –> Administrative Tools –> Domain Security Policy


Step#2: From the Domain Security Policy Window, enable the “Password must meet complexity requirements” under Password policy in Account Policies


Once these steps are done, the password policy will be enforced when the users do a password reset.


Microsoft has some suggestion on how to make your password strong. I find the following tips useful:

  1. The length of password is very important – make it at least 14 characters or more.
  2. Make your password strong with special characters (symbol) in it.
  3. Mix upper and lower case letters to increase complexity.
  4. Remember to use the entire keyboard instead of using common words.
  5. Increase the length by using numbers between the letters.
  6. More complex the better – add punctuation at the beginning.

You might also want to refer to the Microsoft Documentation for detailed examples and Password checker tool