How to Configure DNS Server Settings in Windows 2008

When you install the DNS server role on a Windows Server 2008 or Windows Server 2008 R2 computer, the DNS Manager Microsoft Management Console (MMC) snap-in is automatically installed, providing you with all the tools required to manage and administer DNS. When you install AD DS the DNS zones needed for administering DNS in the AD DS domain are added to your DNS installation. This section introduces you to server-specific settings that you can configure

from the DNS server’s Properties dialog box.

From the DNS Manager snap-in, right-click the DNS server and choose Properties to display the dialog box shown in image below. This dialog box enables you to configure a comprehensive range of server-specific properties. The more important properties are discussed in this section.

 

Forwarding

The act of forwarding refers to the relaying of a DNS request from one server to another one when the first server is unable to process the request. This is especially useful in resolving Internet names to their associated IP addresses. By using a forwarder, the internal DNS server passes off the act of locating an external resource, thereby reducing its processing load and network bandwidth. The use of forwarding is also helpful for protecting internal DNS servers from access by unauthorized Internet users. It works in the following manner:

Step 1. A client issues a request for a fully qualified domain name (FQDN) on a zone for which its preferred DNS) server is not authoritative (for example, an Internet domain such as http://www.google.com).

Step 2. The local DNS server receives this request but has zone information only for the internal local domain and checks its list of forwarders.

Step 3. Finding the IP address of an external DNS server (such as one hosted by the company’s ISP), it forwards the request to the external server (forwarder).

Step 4. The forwarder attempts to resolve the required FQDN. Should it not be able to resolve this FQDN, it forwards the request to another forwarder.

Step 5. When the forwarder is able to resolve the FQDN, it returns the result to the internal DNS server by way of any intermediate forwarders, which then returns the result to the requesting client.

You can specify forwarders from the Forwarders tab of the DNS server’s Properties dialog box, as shown in Figure 4-2. Click Edit to open the Edit Forwarders dialog box shown in Figure 4-3. In the space provided, specify the IP address of a forwarder and click OK or press Enter. The server will resolve this IP address to its FQDN and display these in the Forwarders tab. You can also modify the sequence in which the forwarding servers are contacted by using the Up and Down command buttons, or you can remove a forwarding server by selecting it and clicking Delete.

You can also specify forwarders from the command line by using the dnscmd command. Open an administrative command prompt and use the following command syntax:

dnscmd ServerName /ResetForwarders MasterIPaddress … [/TimeOut Time] [/Slave]

The parameters of this command are as follows:

■ ServerName: Specifies the DNS hostname of the DNS server. You must include this parameter; use a period to specify the local computer.

■ /ResetForwarders: Indicates that you are configuring a forwarder.

■ MasterIPaddress …: Specifies a space-separated list of one or more IP addresses of DNS servers to which queries are forwarded.

■ /TimeOut: Specifies a timeout setting in seconds.

■ /Slave: Determines whether the DNS server uses recursion when querying for the domain name specified by ZoneName.

Conditional Forwarders

You can configure a DNS server as a conditional forwarder. This is a DNS server that handles name resolution for specified domains only. In other words, the local DNS server will forward all the queries that it receives for names ending with a specific domain name to the conditional forwarder. This is especially useful in situations where users in your company need access to resources in another company with a separate AD DS forest and DNS zones, such as a partner company. In such a case, specify a conditional forwarder that directs such queries to the DNS server in the partner company while other queries are forwarded to the Internet. Doing so reduces the need for adding secondary zones for partner companies on your DNS servers.

The DNS snap-in provides a Conditional Forwarders node where you can specify forwarding information. Use the following procedure to specify conditional forwarders:

Step 1. Right-click the Conditional Forwarders node and choose New Conditional Forwarder

Step 2. Type the DNS domain that the conditional forwarder will resolve and the IP address of the server that will handle queries for the specified domain.

Step 3. If you want to store the conditional forwarder information in AD DS, select the check box provided and choose an option in the drop-down list that specifies the DNS servers in your domain or forest that will receive the conditional forwarder information. Then click OK.

Information for the conditional forwarder you have configured is added beneath the Conditional Forwarders node in the DNS Manager snap-in. Name queries for the specified DNS domain will now be forwarded directly to this server.

Root Hints

Whenever a DNS server is unable to resolve a name directly from its own database or with the aid of a forwarder, it sends the query to a server that is authoritative for the DNS root zone. Recall from Chapter 2 that the root is the topmost level in the DNS hierarchy. The server must have the names and addresses of these servers stored in its database to perform such a query. These names and addresses are known as root hints, and they are stored in the cache.dns file, which is found at %systemroot%system32dns. This is a text file that contains NS and A records for every available root server.

When you first install DNS on a server connected to the Internet, it should download the latest set of root hints automatically. You can verify that this has occurred by checking the Root Hints tab of the server’s Properties dialog box. You should see a series of FQDNs with their corresponding IP addresses.

If your internal DNS server does not provide access to Internet name resolution, you can improve network security by configuring the root hints of the internal DNS servers to point to the DNS servers that host your root domain and not to Internet root domain DNS servers. To modify the configuration on this tab, perform one or more of the following actions:

■ Click Add to display the New Name Server Record dialog box, from which you can manually type the FQDNs and IP addresses of one or more authoritative name servers.

■ Select an entry and click Edit to display the Edit Name Server Record dialog box, which enables you to modify it or add an additional IP address to an existing record.

■ Select an entry and click Remove to remove a record.

■ Click Copy from Server to copy a list of root hints from another DNS server. Type the DNS name or IP address in the dialog box that appears. This action is useful if your server was not connected to the Internet at the time DNS was installed.

■ Although this is not a recommended action, you can also edit the cache.dns file using a text editor such as Notepad.

NOTE: You can also use the Configure a DNS Server Wizard to configure root hints for your server. Right-click your server in the console tree of the DNS Manager snap-in and choose Configure a DNS Server. Then select the Configure root hints only (recommended for advanced users only) option from the Select Configuration Action page of the wizard.

Configuring Zone Delegation

As you have seen, you can divide your DNS namespace into a series of zones. You can delegate management of these zones to another location or workgroup within your company by delegating the management of the respective zone. Configuring zone delegation involves creating delegation records in other zones that point to the authoritative DNS servers for the zone being delegated. Doing so enables you to transfer authority as well as providing correct referral to other DNS servers and clients utilizing these servers for name resolution.

The Zone Delegation benefits:

■ You can delegate the administration of a portion of your DNS namespace to another office or department in your company.

■ You can subdivide your zone into smaller zones for load balancing of DNS traffic among multiple servers. This also enables improved DNS name resolution performance and fault tolerance.

■ You can extend the namespace by adding additional subdomains for purposes such as adding new branch offices or sites.

You can use the New Delegation Wizard to create a zone delegation. The wizard uses the information you supplied to create name server (NS) and host (A or AAAA) resource records for the delegated subdomain. Perform the following procedure:

Step 1. Right-click the parent zone in the console tree of DNS Manager and

choose New Delegation. This starts the New Delegation Wizard.

Step 2. Click Next and then enter the name of the delegated subdomain.

Step 3. As shown in next screenshot, the wizard appends the parent zone name to form the FQDN of the domain being delegated. Click Next and then click Add.

Step 4. In the New Name Server Record dialog box, type the FQDN and IP address of the DNS server that is authoritative for the subdomain and then click OK. Repeat if necessary to add additional authoritative DNS servers.

Step 5. The servers you’ve added are displayed on the Name Servers page of the wizard. When finished, click Next and then click Finish.

You can also use the dnscmd utility to perform zone delegation from the command line. Open an administrative command prompt and use the following command:

dnscmd ServerName /RecordAdd ZoneName NodeName [/Aging] [/OpenAcl] [Ttl] NS {HostName|FQDN}

Debug Logging

The DNS server also supports debug logging of packets sent to and from the DNS server to a text file named dns.log. This file is stored in the %systemroot%system32dns folder. To configure logging, right-click the server in the DNS Manager snap-in and choose Properties. Click the Debug Logging tab to receive the dialog box.

By default, no logging is configured. Select the Log packets for debugging check box, which makes all other check boxes available.

To view the DNS log, first stop the DNS service by right-clicking the DNS server in DNS Manager and choosing All Tasks > Stop. Then open the log in either Notepad or WordPad. When you are finished, restart the DNS service by right clicking the DNS server and choosing All Tasks > Start.

Event Logging

The Event Logging tab of the DNS server’s Properties dialog box enables you to control how much information is logged to the DNS log, which appears in Event Viewer. You can choose from one of the following options:

■ No events: Suppresses all event logging (not recommended).

■ Errors only: Logs error events only.

■ Errors and warnings: Logs errors and warnings only.

■ All events: Logs informational events, errors, and warnings. This is the default. Choosing either the Errors only or Errors and warnings option might be useful to reduce the amount of information recorded to the DNS event log.

DNS Security Extensions

DNS in itself is vulnerable to certain types of intrusions such as spoofing, man-in-the-middle, and cache-poisoning attacks. Because of this, DNS Security Extensions (DNSSEC) was developed to add additional security to the DNS protocol. Outlined in Requests for Comments (RFCs) 4033, 4034, and 4035, DNSSEC is a suite of DNS extensions that adds security to the DNS protocol by providing origin authority, data integrity, and authenticated denial of existence. Although an older form of DNSSEC was used in Windows Server 2003 and the first iteration of Windows Server 2008, DNSSEC has been updated completely according to the specifications in the just-mentioned RFCs. The newest form of DNSSEC is available for Windows Server 2008 R2 and Windows 7 only.

DNSSEC enables DNS servers to use digital signatures to validate responses from other servers and resolvers. Signatures are stored in a new type of resource record called DNSKEY within the DNS zone. On resolving a name query, the DNS server includes the appropriate digital signature with the response, and the signature is validated by means of a preconfigured trust anchor. A trust anchor is a preconfigured public key associated with a specific zone. The validating server is configured with one or more trust anchors. Besides DNSKEY, DNSSEC adds RRSIG, NSEC, and DS resource records to DNS. You can view zones that are signed with DNSSEC in the DNS Manager tool, and you can view the trust anchors from the Trust Anchors tab of the DNS server’s Properties dialog box.

To specify a trust anchor, click Add. Provide the information requested in the New Trust Anchor dialog box, including its name and public key value, and then click OK. The public key value must be formatted as a Base64 encoding value; for more information on the public key, refer to http://www.rfc-archive.org/getrfc.php?rfc=4034 Doing so adds the trust anchor to the Trust Anchors tab and enables its use for signing DNS query responses.

Advanced Server Options

The Advanced tab of the DNS server’s Properties dialog box contains a series of options that you should be familiar with.

Server Options

The Server options section of this dialog box contains the following six options, the last three of which are selected by default:

■ Disable recursion: Prevents the DNS server from forwarding queries to other DNS servers, as described later in this section. Select this check box on a DNS server that provides resolution services only to other DNS servers because unauthorized users can use recursion to overload a DNS server’s resources and thereby deny the DNS Server service to legitimate users.

■ BIND secondaries: During zone transfer, DNS servers normally utilize a fast transfer method that involves compression. If UNIX servers running a version of Berkeley Internet Name Domain (BIND) prior to 4.9.4 are present, zone transfers will not work. These servers use a slower uncompressed data transfer method. To enable zone transfer to these servers, select this check box.

■ Fail on load if bad zone data: When selected, DNS servers will not load zone data that contains certain types of errors. The DNS service checks name data using the method selected in the Name Checking drop-down list on this tab.

■ Enable round robin: Enables round robin, as described later in this section.

■ Enable netmask ordering: Prioritizes local subnets so that when a client queries for a hostname mapped to multiple IP addresses, the DNS server preferentially returns an IP address located on the same subnet as the requesting client.

■ Secure cache against pollution: Cache pollution takes place when DNS query responses contain malicious items received from nonauthoritative servers. This option prevents attackers from adding such resource records to the DNS cache. The DNS servers ignore resource records for domain names outside the domain to which the query was originally directed. For example, if you sent a query for que.com and a referral provided a name such as windows-scripting.info, the latter name would not be cached when this option is enabled.

Round Robin

Round robin is a load-balancing mechanism used by DNS servers to distribute name resolution activity among all available DNS servers. If multiple A or AAAA resource records are found in a DNS query (for example, on a multihomed computer), round robin sequences these resource records randomly in repeated queries for the same computer. An example in which round robin is useful is a situation where you have multiple terminal servers in a server farm that users access for running applications. DNS uses round robin to randomize the sequence in which users accessing the terminal servers reach given servers.

By default, round robin is enabled on Windows Server 2008 R2 DNS servers. You can verify or modify this setting from the Advanced tab of the DNS server’s Properties dialog box already shown in Figure 4-10. Select or clear the check box labeled Enable round robin as required.

Reverse DNS Testing for Anti-Spam

Reverse DNS (rDNS) queries are very often employed to identify email servers that are incorrectly configured. Failing such a test, results in many emails being rejected. Today we discuss how to setup DNS in order for our email servers to pass this test.

A reverse DNS (rDNS) query aims to identify the domain name for a given IP address. The query is fed with an IP, which is looked up at the DNS. If the IP has been published correctly through a DNS PTR record, the query returns the domain name for this IP.

This type of lookup is referred to as a reverse DNS query since it performs the inverse operation of a typical (forward) DNS query, where the IP address is retrieved for a given domain name.

Here we want our servers to pass the anti-spam rDNS tests, so we are considering the case where the tests are performed by foreign servers when we send out emails.

DNS MX, A, and PTR Records

We already mentioned PTR records, so let’s expand further on this point. This article is not intended for DNS gurus or those aspiring to become one, so I don’t plan to delve into any complex DNS discussions. We just look at a simple scenario that helps us explain how rDNS based anti-spam tests work.

You will be certainly aware that whenever setting up an internet facing email server for public consumption, it is required to create the necessary MX and A records at the DNS. These allow foreign senders to perform forward DNS queries and discover the IP of our servers, responsible for receiving incoming emails. In this case the need for MX and A records is almost impossible to overlook. Without these, we won’t receive any emails from outside.

As an example this is what our MX and A record could look like. These are created at our external DNS server.
exchangeinbox.com. IN MX 10 mail.exchangeinbox.com.
mail.exchangeinbox.com. IN A 123.123.123.123

Here the MX record is identifying the host handling inbound emails for exchangeinbox.com. The A record is identifying the IP for this host. It is possible to have multiple MX records for failover, in which case the MX preference value (here set to 10) comes into play. The inbound server with lowest numeric preference value is the one a sender should try first. I am not going to delve much into multiple MX records. Let me just say that spammers will target your inbound email server irrespective of the MX preference value. Indeed they sometimes target servers with higher preference hoping that these are not protected by a spam filter.

In comparison to MX and A records, the need for PTR records is initially less obvious. Without it, emails will still flow in and out. However because of the wide adoption of the rDNS anti-spam tests, missing a PTR record causes the rejection of many outgoing emails.

In this discussion I emphasized two keywords, incoming and outgoing. The PTR record for our mail server has an impact on our outgoing emails. Missing, or even worst incorrectly configuring the PTR, may cause our emails to be classified as spam.

PTR records are created for us by the ISP providing the fixed IP and internet connectivity to our email server. We need to request the ISP to create a PTR so as the IP identifies our outgoing email server. This also means that the PTR is not located on the same DNS server as our MX and A records.

Most likely you will only have one email server handling both inbound and outbound emails. So if we continue on the MX and A records examples shown earlier, the PTR record would identify the name mail.exchangeinbox.com.

In more complex scenarios you may have more than one email server, one of which might be dedicated exclusively to deliver outgoing emails. This is a case worth watching out for because it is easier to get it wrong. Let’s say we have an inbound server named mail.exchangeinbox.com and an outbound server namedmailout.exchangeinbox.com. In this case, we need both a PTR for the outbound server IP pointing tomailout.exchangeinbox.com and also an A record such as:
mailout.exchangeinbox.com. IN A 222.222.222.222

The rule here is that our outbound server must have both a PTR and an A record. Starting from the host name we have to be able to get the IP through a forward DNS lookup. Starting from the IP we have to be able to get the host name through an rDNS lookup.

The Anti-Spam rDNS Test

We now see how the result of an rDNS query is employed in spam filtering. In practice there exists more than one method to employ rDNS in spam filtering. However here we discuss the most common type, the one that we should make sure our server never fails. This test goes like this:

1. The receiving server determines the IP of the sender. This could be obtained directly from the connection or extracted from the email Received headers.
2. Through an RDNS query the host name for this IP is retreived.
3. Next the host name is fed to a forward DNS query, obtaining the IP from the A record.
4. The test is successful if the sender IP matches the one returned by the forward DNS query.

This type of cross verification tests whether all DNS records are consistently identifying the same sender uncovering spoofing attempts.

Consider the case where a spammer legitimately obtains a fixed IP and gets the ISP to create a PTR record for him, pointing to mail.exchangeinbox.com. The spammer can also forge the email content including the ‘From’ header to make it look like it is a true exchangeinbox.com email. What the spammer cannot do, is create the A record, since the exchangeinbox.com DNS is controlled by its legitimate owner. Thus despite all his efforts the spammer will still fail the test.

Another example is the case involving infected machines that are suddenly transformed into an email server for spam distribution. In this case spoofing is even easier to identify since the spammer has no ability to create any of the DNS records.

Final Tips

Today we discussed a very common test used in spam filtering, targeting one of the key weaknesses in the spam distribution chain, the sender Identity.

The test is independent of email content. It also does not depend on information from external providers as in RBLs and other reputation services. It simply relies on the email server DNS configuration, something the sender is supposed to have control on.

This type of filter can cause some headaches to inexperienced administrators who too often overlook the need to create PTR records. Indeed some do question whether it is correct to block emails based on this criterion especially in the light that legitimate senders sometimes are caught in the trap. The counter argument is that accepting emails from incorrectly configured servers opens a window for spammers to exploit. The benefit of closing this window justifies the loss of some legitimate emails.

In all cases what really matters is that many are already employing such a filter so we did better have all necessary DNS records in place. Once we have the peace of mind that our emails aren’t being blocked we can quietly decide whether or not we also want to filter emails in the same manner.

Troubleshooting Error Code 0×8004210e

When users attempt to download their email they sometimes will receive an error message such as:

“Task ‘<Server_Name> – Receiving’ reported error (0×8004210E): ‘Yουr mailbox іѕ temporarily unavailable bесаυѕе another e-mail message іѕ being delivered tο іt οr another mail application іѕ accessing іt. Thе server responded: -ERR box locked”

This error code, 0×8004210e, is sent from your Internet Service Provider and can be a result of a locked mailbox. Sometimes other error messages may appear that refer to a “POP Lock” (Post Office Protocol) or “Box Lock”. These error messages can be received when using email clients such as Microsoft Outlook, Outlook Express, Windows Mail and others.

The error message can be generated because of network problems, malformed email messages, or more than one email client being configured to poll the server. What happens is that the lock file – which is used to stop more than one person from logging into the account at once – fails to be deleted at the end of the POP3 session. It then prevents the end user from logging in again and thus the error code, 0×8004210e is sent.

One resolution is to simply restart your mail client. If your end user cannot wait for a restart, or if a restart is not convenient at the time, then the user can try to access their email from a webmail account. If that fails then the problem may lie with the Internet Service Provider and in that case the administrator should contact the ISP support desk.

If restarting the mail client and contacting the ISP are not successful resolutions then the following workarounds should be tried:

1. Limit the end user’s access to email from only one email client. For the particular end user with the email issue an administrator can restrict the end user’s access to all other email clients. Only Microsoft Outlook access should be allowed for the end user. One method is to disable the other email clients. Another method would be to rename the end user’s account on the other email clients thereby preventing further email messages from being downloaded to that particular client. In addition, email devices such as a Blackberry, iPhone, οr similar device, thаt download the end users email, should also be disabled.
2. Another workaround is to temporarily disable antivirus software and anti-spam software on the end user’s system. Unfortunately by disabling such software on an end user’s system this will render that system vulnerable to computer attacks. This should be the last choice and only be performed temporarily as systems are left open to computer viruses and other malicious programs. The reason why disabling the antivirus and anti-spam software is a workaround is because these software applications installed on the client can have problems with interpreting the email and does not complete. So it doesn’t try to download the next email message from the server. To implement this workaround an administrator can follow this procedure:
   a. All antivirus and anti-spam software should be disabled on the client system. Likewise, disabling any email scanning features should also be performed.
   b. From Outlook, click on Send/Receive to download any malformed email messages from the email server.
   c. Once email has been downloaded then re-enable the antivirus and the anti-spam software on the client system.
   d. Email messages can now be opened.
3. A web email client can be used to access the end user’s email messages and then delete the malformed email from the mailbox. A safe practice would be to target those email messages that are greater than one megabyte in size and then delete them.
4. A fourth workaround is to enable server-side anti-spam and antivirus software on the email accounts using the web control panel. Most malformed emails will be prevented from reaching the end user’s inbox and thus stop the error code (0×8004210E) from being generated.

Administrators should be cautious and fully aware of the risks associated with turning off antivirus and anti-spam software. It would be wise to make a backup of the end user’s system before turning off these applications. And if the end user is accessing their email from within a virtual environment then this will also help to lower the risk of any potential damages.

An alternative solution to Rename Domain with Exchange 2007/2010

Recently my company registered a new domain name and wanted to me to investigate best possible way to rename domain internally, change websites (hosted on IIS) publicly accessible CNAME to new domain name and change email address for entire organization. Fun hahh!! Google search appears that domain rename possible in win2k3 AD and exchange 2003 SP1.  However, according to Microsoft TechNet I can not rename Windows 2008 native domain with Exchange 2007 . what happen to those who are in the following situation:

• Rename Business registration
• Merger and/or Acquisition between companies
• Change of ownership

If your management decide to have new user account@newdomain, email addresses@newdomain and websites with new domain name. Now you will not have a choice but  find out a solution regardless of who says what. In this article (Ref: Plan A), I will investigate and share with you what happen if you rename domain on a test environment similar to my organisation i.e. Microsoft Active Directory 2008 and Exchange 2007/2010. Those who are in my situation, I will explain (Ref: Plan B) how I can accomplish same objectives with alternative deployment that means without messing around AD domain and Exchange 2007/2010.  I know plan A is going to fail but worthwhile to produce documents to management and go for plan B. So that business runs smoothly. when time perfect and fund is available then rebuild Microsoft messaging systems for entire organization.

Do NOT perform these steps in a production environment. Domain rename is NOT supported when Exchange 2007/2010 installed in a member server.

Rename Domain on a Testbed

Objectives:

• Rename Domain
• Migrate IIS to new domain
• Fix GPO and Exchange (only applicable for Exchange 2003)

Assumptions:

Steps involve:

• Set up your control station for the domain rename operation.
• Freeze the Forest Configuration
• Back up all the domain controllers in your forest.
• Generate the current forest description.
• Specify the new forest description.
• Generate domain rename instructions
• Push domain rename instructions to all domain controllers, and verify DNS readiness.
• Verify the readiness of the domain controllers.
• Execute the domain rename instructions
• Update the Exchange configuration, and restart the Exchange servers (Only applicable for Exchange 2003 SP1)
• Unfreeze the forest configuration
• Re-establish external trusts
• Fix Group Policy objects (GPOs) and links.

Precaution: Use the following link for Active Directory Backup and Restore in Windows Server 2008 or keep your resume handy

To verify the forest functionality to Windows Server 2008

1. Open Active Directory Domains and Trusts.
2. In the scope pane, right-click Active Directory Domains and Trusts and then click Raise Forest Functional Level.
3. In the Select an available forest functional level box, click Windows Server 2008, and then click Raise.
4. Click OK to raise the forest functionality, and then click OK again.

To analyze and prepare DNS zones for domain rename

1. Compile a list of DNS zones that need to be created.
2. Use the DNS MMC snap-in to create the required DNS zones compiled in step 1.
3. Configure DNS zones according to “Add a forward lookup zone” in Windows Server 2008.
4. Configure dynamic DNS update according to “Allow dynamic updates” in Windows Server 2008.

To generate the current forest description file

In windows server 2008, rendom and GPFix utility are available in %Windir%system32 folder. If you change your directory into c:Windowssystem32 and run rendom /list then domainlist.xml will be placed in same directory.

1. On the control station, open a command prompt and change to the X:DomainRename directory.
2. At the command prompt, type rendom /list the following command and press ENTER:
3. Save a copy of the current forest description file (domainlist.xml) generated in step 2 as domainlist-save.xml for future reference by using the following copy command: copy domainlist.xml domainlist-save.xml

To edit the domainlist.xml file

1. Using a simple text editor such as Notepad.exe, open the current forest description file domainlist.xml generated in “STEP 3: Generate the Current Forest Description” earlier in this document.
2. Edit the forest description file, replacing the current DNS and/or NetBIOS names of the domains and application directory partitions to be renamed with the planned new DNS and/or NetBIOS names.

To review the new forest description in domainlist.xml

At the command prompt, type the following and then press ENTER: rendom /showforest

To generate the domain rename instructions and upload them to the domain naming master

1. On the control station, open a command prompt.
2. From within the X:DomainRename directory, execute the following command: rendom /upload
3. Verify that the domain rename tool created the state file dclist.xml in the directory X:DomainRename and that the state file contains an entry for every domain controller in your forest

To discover the DNS host name of the domain naming master

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: Dsquery server –hasfsmo name

To force synchronization of changes made to the domain naming master

The following procedure forces the Active Directory changes initiated at the Domain Naming master DC in STEP 4 to replicate to all DCs in the forest.

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: repadmin /syncall /d /e /P /q DomainNamingMaster

where DomainNamingMaster is the DNS host name of the domain controller that is the current domain naming master for the forest.

To verify the readiness of domain controllers in the forest

1. On the control station, open a command prompt and change to the X:DomainRename directory

2. At the command prompt, type the following command and then press ENTER: rendom /prepare

3. Once the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have achieved the

To execute the domain rename instructions on all domain controllers

1. On the control station, open a command prompt.
2. At the command prompt, type the following and then press ENTER: rendom /execute
3. When the command has finished execution, examine the state file domainlist.xml to determine whether all domain controllers have reached either the Done state or the Error state.
4. If the domainlist.xml file shows any DCs as remaining in the Prepared state, repeat step 2 in this procedure as many times as needed until the stopping criterion is met.

To force Rendom /execute to re-issue the RPC to a DC in the Error state

1. In the domainlist.xml file, locate the <Retry></Retry> field in the domain controller entry for the DC that you believe should be retried.
2. Edit the domainlist.xml file such that the field reads <Retry>yes</Retry> for that entry.
3. The next execution of the rendom /execute command will re-issue the execute-specific RPC to that DC.

To fix up DFS topology in every renamed domain

On the control station, open a command prompt. For each Dfs root, if any of the topology components as described above needs to be fixed, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

dfsutil /RenameFtRoot /Root:DfsRootPath /OldDomain:OldName /NewDomain:NewName /Verbose

-Where-

DfsRootPath is the DFS root to operate on, e.g., \microsoftguru.com.aupublic.

OldName is the exact old name to be replaced in the topology for the Dfs root.

NewName is the exact new name to replace the old name in the topology.

To fix up Group Policy in every renamed domain

1. On the control station, open a command prompt and change to the X:DomainRename directory.
2. At the command prompt, type the following command (the entire command must be typed on a single line, although it is shown on multiple lines for clarity) and press ENTER:

gpfixup /olddns:OldDomainDnsName /newdns:NewDomainDNSName /oldnb:OldDomainNetBIOSName

/newnb:NewDomainNetBIOSName /dc:DcDnsName 2>&1 >gpfixup.log

-Where-

OldDomainDnsName is the old DNS name of the renamed domain.

NewDomainDnsName is the new DNS name of the renamed domain.

OldDomainNetBIOSName is the old NetBIOS name of the renamed domain.

NewDomainNetBIOSName is the new NetBIOS name of the renamed domain.

DcDnsName is the DNS host name of a domain controller in the renamed domain, preferably the PDC emulator, that successfully completed the rename operation with a final Done state in the dclist.xml state file in “STEP 8: Execute Domain Rename Instructions” earlier in this document.

For example,

gpfixup /olddns:wolverine.com.au /newdns:microsoftguru.com.au /oldnb:wolverine /newnb:microsoftguru /dc:dc.wolverine.com.au 2>&1 >gpfixup1.log

To force replication of the Group Policy fix-up changes made at the DC named in DcDNSName in above step of this procedure to the rest of the DCs in the renamed domain, type the following and then press ENTER: repadmin /syncall /d /e /P /q DcDnsName NewDomainDN

-Where-

DcDnsName is the DNS host name of the DC that was targeted by the gpfixup command.

NewDomainDN is the distinguished name (DN) corresponding to the new DNS name of the renamed domain.

Repeat steps  in this procedure for every renamed domain. You can enter the commands in sequence for each renamed domain.

For Example, repadmin /syncall /d /e /P /q dc.microsoftguru.com.au dc=microsoftguru,dc=com, dc=au

To update the DNS name of the CA machine

1. On the CA machine, open registry editor and locate the entry CAServerName under HKLMSystemCurrentControlSetCertSvcConfigurationYourCAName.
2. Change the value in CAServerName to correspond to the new DNS host name.

To update the Web enrolment file

To enable proper Web enrollment for the user, you must also update the file that is used by the ASP pages used for Web enrollment. The following change must be made on all CA machines in your domain.

1. On the CA machine, search for the certdat.inc file (if you have used default installation settings, it should be located in the %windir%system32certsrv directory).

2. Open the file, which appears as follows:

<%’ CODEPAGE=65001 ‘UTF-8%>

<%’ certdat.inc – (CERT)srv web – global (DAT)a

‘ Copyright (C) Microsoft Corporation, 1998 – 1999 %>

<% ‘ default values for the certificate request

sDefaultCompany=””

sDefaultOrgUnit=””

sDefaultLocality=””

sDefaultState=””

sDefaultCountry=””

‘ global state

sServerType=”Enterprise” ‘vs StandAlone

sServerConfig=”OLDDNSNAMEYourCAName”

sServerDisplayName=”YourCAName”

nPendingTimeoutDays=10

‘ control versions

sXEnrollVersion=”5,131,2510,0″

sScrdEnrlVersion=”5,131,2474,0″

%>

3. Change the SServerConfig entry to have the NewDNSName of the CA machine.

To perform attribute clean up after domain rename

1. On the control station, open a command prompt.
2. At the command prompt, from within the X:DomainRename directory, execute the following command: rendom /clean

Command-line usage to run XDR-fixup.exe

XDR-fixup.exe /s:start_domainlist.xml /e:end_domainlist.xml [/user:username /pwd:password | *] [/trace:tracefile] /changes:changescript.ldf /restore:restorescript.ldf [/?]

Note This command is one line. It has been wrapped for readability.

Command-line usage to verify XDR-fixup.exe

Use the following command line to verify the changes that are made by XDR-fixup.exe:

XDR-fixup /verify:restorescript.ldf /changes:verifycorrections.ldf

To unfreeze the forest configuration

From within the X:DomainRename directory, execute the following command: rendom /end

To force remove domain member if fails to join new domain using following command. Then re-join domain manually.

netdom remove <machine-name> /Domain:<old-domain> /Force”

To use Control Panel to check for primary DNS suffix update configuration for a computer

The following procedures explain two ways to view the setting for a member computer that determines whether the primary DNS suffix changes when the name of the membership domain changes.

1. On a member computer, in Control Panel, double-click System.

2. Click the Computer Name tab and then click Change.

3. Click More and then verify whether Change primary domain suffix when domain membership changes is selected.

4. Click OK until all dialog boxes are closed.

To use the registry to check for primary DNS suffix update configuration for a computer

1. On the Start menu, click Run.

2. In the Open box, type regedit and then click OK.

3. Navigate to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

4. Verify whether the value of REG_RWORD SyncDomainWithMembership is 0×1. This value indicates that the primary DNS suffix changes when the domain membership changes.

To determine whether Group Policy specifies the primary DNS suffix for a computer

1. On a member computer, perform one of the following steps:
2. At a command prompt, type gpresult. In the output, under Applied Group Policy objects, check to see whether Primary DNS Suffix is listed.

Open the Resultant Set of Policy Wizard, as follows:

In Active Directory Users and Computers, right-click the computer object, click All Tasks, and then click Resultant Set of Policy (Logging).

Open a command prompt and then type: ipconfig /all

Check the Primary DNS Suffix in the output. If it does not match the primary DNS suffix that is specified in the System Control Panel for the computer (see “To use Control Panel to check for primary DNS suffix update configuration for a computer” earlier in this document), then the Primary DNS Suffix Group Policy is applied.

u In the registry, check for the presence of the entry Primary DNS Suffix under HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftSystemDNSclient. If a value is present, then the Primary DNS Suffix Group Policy is applied to the computer.

To install Support Tools

1. On the Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, or Windows Server 2003 Datacenter Edition operating system CD, double-click the Support folder.

2. In the Support folder, double-click the Tool folder and then run suptools.msi.

To use ADSI Edit to add DNS suffixes to msDS‑AllowedDNSSuffixes

The attribute msDS‑AllowedDNSSuffixes is an attribute of the domain object. Therefore, you must set DNS suffixes for each domain whose name is going to change.

1. On the Start menu, point to Programs, Windows Server 2003 Support Tools, Tools, and then click ADSI Edit.

2. Double-click the domain directory partition for the domain you want to modify.

3. Right-click the domain container object, and then click Properties.

4. On the Attribute Editor tab, in the Attributes box, double-click the attribute msDS‑AllowedDNSSuffixes.

5. In the Multi-valued String Editor dialog box, in the Value to add box, type a DNS suffix and then click Add.

6. When you have added all the DNS suffixes for the domain, click OK.

7. Click OK to closed the Properties dialog box for that domain.

8. In the scope pane, right-click ADSI Edit and click Connect to.

9. Under Computer, click Select or type a domain or server.

10. Type the name of the next domain for which you want to set the primary DNS suffix, and then click OK.

11. Repeat steps 2 through 7 for that domain.

12. Repeat steps 8 through 10 to select each subsequent domain and repeat steps 2 through 7 to set the primary DNS suffix for each subsequent domain that is being renamed.

To apply the Group Policy setting Primary DNS Suffix to groups of member computers

1. In Active Directory Users and Computers, right-click the domain or organizational unit that contains the group of computers to which you are applying Group Policy.

-Or-

In Active Directory Sites and Services, right-click the site object that contains the computers to which you are applying Group Policy.

2. Click the Group Policy tab.

3. In the Group Policy object Links box, click the Group Policy object that you want to contain the Primary DNS Suffix setting.

-Or-

To create a new Group Policy object, click New and then type a name for the object.

4. With the Group Policy object selected, click Edit.

5. Under Computer Configuration, click to expand Administrative Templates, Network, and then click DNS Client.

6. In the results pane, double-click Primary DNS Suffix.

7. Click Enabled, and then in the Enter a primary DNS suffix box, type the DNS suffix for the domain whose member computers are in the group you selected in Step 1.

8. Click OK.

9. Close the Group Policy dialog box, and then close the properties page for the selected object.

To configure the redirecting alias DNS entry

1. In the DNS MMC snap-in, expand the DNS server node to expose the old DNS zone.

2. Right-click the old DNS zone.

3. Click New Alias (CNAME ).

4. In the Alias name box, type the original fully qualified domain name (FQDN) of the HTTP Server..

5. In the Fully qualified domain name for target host box, type the new FQDN of the HTTP Server, and then click OK.

At this point you can test the redirection by pinging the FQDN of the old HTTP server. The ping should be remapped to the new FQDN of the HTTP server.

Issues involving domain rename:

• XDR-Fixup tool does not work on Exchange 2010
• Exchange SMTP stops functioning
• Exchange organization initialization fails

Simple alternative solutions without renaming domain

Microsoft does not support domain rename if Exchange 2007 installed in member server. So what could be work around if you have to have new user account, corresponding emails account and web sites with new domain name without renaming domain.

• Prepare a control workstation station and log on as a domain admin, schema admin and enterprise admin
• Create a new range of IP in your infrastructure
• Prepare an windows server 2008 and promote as your new primary domain with new domain name
• Create External trust between two domains
• Ask your ISP Add new Host (A) and MX record with new domain

• Point this new MX record to existing SMTP server
• Add new domain into trusted domain list

• Add new email policy for new domain

• Change default email address to new email addresses through email property of mailbox using Exchange management console

• Migrate IIS web sites to new web server
• Redirect CNAME record to new websites for customers and stakeholder
• Add 301 redirect using Google webmaster if necessary
  

10 Core Concepts that Every Windows Network Admin Must Know

Introduction

I thought that this article might be helpful for Windows Network Admins out there who need some “brush-up tips” as well as those who are interviewing for network admins jobs to come up with a list of 10 networking concepts that every network admin should know.

So, here is my list of 10 core networking concepts that every Windows Network Admin (or those interviewing for a job as one) must know:

1.     DNS Lookup

The domain naming system (DNS) is a cornerstone of every network infrastructure. DNS maps IP addresses to names and names to IP addresses (forward and reverse respectively). Thus, when you go to a web-page like http://www.windowsnetworking.com, without DNS, that name would not be resolved to an IP address and you would not see the web page. Thus, if DNS is not working “nothing is working” for the end users.

DNS server IP addresses are either manually configured or received via DHCP. If you do an IPCONFIG /ALL in windows, you will see your PC’s DNS server IP addresses.

Figure 1: DNS Servers shown in IPCONFIG output

So, you should know what DNS is, how important it is, and how DNS servers must be configured and/or DNS servers must be working for “almost  anything” to work.

When you perform a ping, you can easily see that the domain name is resolved to an IP (shown in Figure 2).

Figure 2: DNS name resolved to an IP address

For more information on DNS servers, see Brian Posey’s article on DNS Servers.

2.     Ethernet & ARP

Ethernet is the protocol for your local area network (LAN). You have Ethernet network interface cards (NIC) connected to Ethernet cables, running to Ethernet switches which connect everything together. Without a “link light” on the NIC and the switch, nothing is going to work.

MAC addresses (or Physical addresses) are unique strings that identify Ethernet devices. ARP (address resolution protocol) is the protocol that maps Ethernet MAC addresses to IP addresses. When you go to open a web page and get a successful DNS lookup, you know the IP address. Your computer will then perform an ARP request on the network to find out what computer (identified by their Ethernet MAC address, shown in Figure 1 as the Physical address) has that IP address.

3.     IP Addressing and Subnetting

Every computer on a network must have a unique Layer 3 address called an IP address. IP addresses are 4 numbers separated by 3 periods like 1.1.1.1.

Most computers receive their IP address, subnet mask, default gateway, and DNS servers from a DHCP server. Of course, to receive that information, your computer must first have network connectivity (a link light on the NIC and switch) and must be configured for DHCP.

You can see my computer’s IP address in Figure 1 where it says IPv4 Address 10.0.1.107. You can also see that I received it via DHCP where it says DHCP Enabled YES.

Larger blocks of IP addresses are broken down into smaller blocks of IP addresses and this is called IP subnetting. I am not going to go into how to do it and you do not need to know how to do it from memory either (unless you are sitting for a certification exam) because you can use an IP subnet calculator, downloaded from the Internet, for free.

4.     Default Gateway

The default gateway, shown in Figure 3 as 10.0.1.1, is where your computer goes to talk to another computer that is not on your local LAN network. That default gateway is your local router. A default gateway address is not required but if it is not present you would not be able to talk to computers outside your network (unless you are using a proxy server).

Figure 3: Network Connection Details

5.     NAT and Private IP Addressing

Today, almost every local LAN network is using Private IP addressing (based on RFC1918) and then translating those private IPs to public IPs with NAT (network address translation). The private IP addresses always start with 192.168.x.x or 172.16-31.x.x or 10.x.x.x (those are the blocks of private IPs defined in RFC1918).

In Figure 2, you can see that we are using private IP addresses because the IP starts with “10”. It is my integrated router/wireless/firewall/switch device that is performing NAT and translating my private IP to my public Internet IP that my router was assigned from my ISP.

6.     Firewalls

Protecting your network from malicious attackers are firewalls. You have software firewalls on your Windows PC or server and you have hardware firewalls inside your router or dedicated appliances. You can think of firewalls as traffic cops that only allow certain types of traffic in that should be in.

For more information on Firewalls, checkout our Firewall articles.

7.     LAN vs WAN

Your local area network (LAN) is usually contained within your building. It may or may not be just one IP subnet. Your LAN is connected by Ethernet switches and you do not need a router for the LAN to function. So, remember, your LAN is “local”.

Your wide area network (WAN) is a “big network” that your LAN is attached to. The Internet is a humongous global WAN. However, most large companies have their own private WAN. WANs span multiple cities, states, countries, and continents. WANs are connected by routers.

8.     Routers

Routers route traffic between different IP subnets. Router work at Layer 3 of the OSI model. Typically, routers route traffic from the LAN to the WAN but, in larger enterprises or campus environments, routers route traffic between multiple IP subnets on the same large LAN.

On small home networks, you can have an integrated router that also offers firewall, multi-port switch, and wireless access point.

For more information on Routers, see Brian Posey’s Network Basics article on Routers.

9.     Switches

Switches work at layer 2 of the OSI model and connect all the devices on the LAN. Switches switch frames based on the destination MAC address for that frame. Switches come in all sizes from small home integrated router/switch/firewall/wireless devices, all the way to very large Cisco Catalyst 6500 series switches.

10. OSI Model encapsulation

One of the core networking concepts is the OSI Model. This is a theoretical model that defines how the various networking protocols, which work at different layers of the model, work together to accomplish communication across a network (like the Internet).

Unlike most of the other concepts above, the OSI model isn’t something that network admins use every day. The OSI model is for those seeking certifications like the Cisco CCNA or when taking some of the Microsoft networking certification tests. OR, if you have an over-zealous interviewer who really wants to quiz you.

To fulfill those wanting to quiz you, here is the OSI model:

• Application – layer 7 – any application using the network, examples include FTP and your web browser
• Presentation – layer 6 – how the data sent is presented, examples include JPG graphics, ASCII, and XML
• Session – layer 5 – for applications that keep track of sessions, examples are applications that use Remote Procedure Calls (RPC) like SQL and Exchange
• Transport – layer 4 -provides reliable communication over the network to make sure that your data actually “gets there” with TCP being the most common transport layer protocol
• Network – layer 3 -takes care of addressing on the network that helps to route the packets with IP being the most common network layer protocol. Routers function at Layer 3.
• Data Link – layer 2 -transfers frames over the network using protocols like Ethernet and PPP. Switches function at layer 2.
• Physical – layer 1 -controls the actual electrical signals sent over the network and includes cables, hubs, and actual network links.

At this point, let me stop degrading the value of the OSI model because, even though it is theoretical, it is critical that network admins understand and be able to visualize how every piece of data on the network travels down, then back up this model. And how, at every layer of the OSI model, all the data from the layer above is encapsulated by the layer below with the additional data from that layer. And, in reverse, as the data travels back up the layer, the data is de-encapsulated.

By understanding this model and how the hardware and software fit together to make a network (like the Internet or your local LAN) work, you can much more efficiently troubleshoot any network. For more information on using the OSI model to troubleshoot a network, see my articles Choose a network troubleshooting methodology and How to use the OSI Model to Troubleshoot Networks.

Summary

I can’t stress enough that if you are interviewing for any job in IT, you should be prepared to answer networking questions. Even if you are not interviewing to be a network admin, you never know when they will send a senior network admin to ask you a few quiz questions to test your knowledge. I can tell you first hand, the questions above are going to be the go-to topics for most network admins to ask you about during a job interview. And, if you are already a windows network admin, hopefully this article serves as an excellent overview of the core networking concepts that you should know. While you may not use these every day, knowledge of these concepts is are going to help you troubleshoot networking problems faster.

Internet Explorer Security Patch (978207) Released

Internet Explorer Security Patch (978207) Released

IE users can update their browser to the device through Microsoft Windows Update.
As promised, Microsoft posted a patch (read the security bulletin from Microsoft) for its Internet browser (versions 6, 7 and 8). Its installation is done without intervention for users who have enabled automatic update of Windows. The others will go through the Windows Update (accessible from the Start menu – All Programs in Windows). 

Microsoft also recommends the user of Internet using Internet Explorer 6 or 7 to upgrade to the latest version, 8.0, its browser, supposedly more secure. 

Microsoft promises the imminent release of a patch to address the vulnerability of its web browser. Usually the company publishes its updated once a month. But given recent events, the firm founded by Bill Gates to change their habits and customs. 

When the “Aurora operation” conducted against Google in China, including hackers have exploited a security hole in Internet Explorer. Following this attack, the German and French authorities advised their citizens to stop using this software until a patch is available. 

While the advance publication of the patch, the publisher continues to minimize the risks associated with using their browser. “At this stage, the threats are very limited. And the successful attacks that we know will affect Internet Explorer 6 (…) Given the impact of this situation and it has created confusion among consumers, we will post an update to correct this vulnerability “. 

This patch will be available “in the evening” of January 21, 2010, in the words used by Microsoft in a statement issued on Thursday (Update, January 21 at 15.45).
Want to tell you about secure VPN service which allows you to surf the internet anonymously and safely and bypass proxy servers and filters imposed by your ISP, office or school. 
By using a secure and anonymous connection you can get full internet access in places that censor or block your connection and full protection at open Wifi hotspots. 
Use Skype, ICQ and MSN, download torrents and access any website you like when traveling to countries that block these programs, so it is perfect of ex-pats and business users.

Benefits of using our VPN service:
– Provides a layer of security and anonymity
– Bypass your ISP restrictions
– Download torrents 24 hours a day
– Use Skype, Yahoo and Google Talk in Middle East and Asia
– Access poker/gambling/adult sites anonymously from anywhere
– We give you a new IP address from any of 10 countries

Our servers are located in Germany, Switzerland, Netherlands, Luxemburg, Israel, Great Britain, Canada, United States, Malaysia and Estonia.

Our prices
Our prices starts from .31 for 3 hours or .3 for 1 day! 
We accept most Credit Cards and all accounts are created automatically after payment.
Check full price list through the link at the bottom of this message. 

Affiliate program
Can you find new customers? We’re ready to pay for it. 
You will recieve 20% from attracted customer’s payment on your own account. 

p.s. Dear moderator. Probably I submitted this post to wrong category. I apologize for this. Please move this thread to proper category and I’ll be able to post news and discounts here. Thanks!

http://reviews-mann.blogspot.com/2010/07/javafx-mobile-for-cell-phones.html