1)x11vnc: Installed on the Linux machine to use as the VNC server.
2) TightVNC: Installed on the Windows machine to use as the VNC client.
Installing the windows software is straight forward for most users. Just download the installer and double click. For many Windows users, the installation of the Linux software might not be as straight-forward.
Of course the Linux installation will depend upon your distribution. But basically all you have to do is follow these steps:
1. Open up your Add/Remove Software tool (such as Synaptic, Ubuntu Software Center, gnome-packagekit, etc)
2. Search for "x11vnc" (no quotes)
3. Select the results for installation.
4. Click Apply to install.
Now, if you are more comfortable with the command line you can install the Linux software like so:
1. Open up a terminal window.
2. Issue a command like sudo apt-get install x11vnc (this will depend upon the distribution you use).
Once all of the software is installed, you are ready to go.
The Linux side
This is really quite easy. All you need to do is start the x11vnc server. If you look at the manual page for x11vnc (issue the command man x11vnc) you will see numerous options available for the server. One of those options you might want to consider is the -forever option. If you don't add this option to the command your x11vnc server will die as soon as the client quits the session.
So the command you will want to run, from the terminal, is:
x11vnc -forever
You will notice you do not get your prompt back. Even if you add the & character, x11vnc will not return you your prompt. Because of this, you might want to consider adding a line like x11vnc -forever to the end of your /etc/rc.local file. This will ensure your x11vnc server is started at boot.
The Windows side
Now it's time to connect. You've already installed TightVNC on the Windows machine so go to the Start menu and fire up TightVNC. When you open the tool up a small window will appear that allows you to enter an address for the connection as well as open up the Options window.
The OSI model consists of seven layers, as follows (working from the bottom up):
Physical layer: This is the layer where the network hardware operates. Rules for this layer govern the
types of connectors used, what types of signaling techniques carry data across the network, and the
types of cable or other networking media that the physical, tangible part of the network uses. In some
sense, this is the only part of the OSI model that you can see and touch.
Data Link layer: This layer handles communication with the network hardware. For outbound
messages, the Data Link layer enables the conversion of the bits that computers use to represent data
into equivalent signals needed to move data across the network. For inbound messages, it reverses
the process by enabling the conversion of signals into their equivalent bits. The Data Link layer is also
where low-level hardware addresses for individual network interface cards (NICs) and other devices
are handled.
Network layer: This layer routes messages between senders and receivers, which means that it also
handles translation between human-readable network addresses and computer-readable network
addresses (which are not the same as the hardware addresses that the Data Link layer handles).
Each message that passes through this layer includes the sender's and the receiver's addresses to
identify the parties involved. The Network layer moves data from sender to receiver when they aren't
both attached to the same cable segment.
Transport layer: This layer chops up large messages into so-called Protocol Data Units (PDUs), or
packets, and sends them across a network. It also puts PDUs back together to reconstitute messages
upon receipt. The Transport layer can also include data integrity checks by adding a bit pattern to each
message based on a mathematical calculation before sending. This same calculation is repeated by
the sender, and the result is compared to the value calculated beforehand. If both values agree, the
Transport layer assumes that the transmission was accurate and correct; if they don't agree, the
Transport layer requests that the PDU be resent. This integrity function is optional; therefore, some
Transport layer protocols include an integrity check and others don't.
Session layer: This layer sets up ongoing network conversations (called sessions) between sender
and receiver. This kind of ongoing connection makes it easier for computers to exchange large
amounts of data, or to maintain a connection when data moves regularly between both parties to a
session. Therefore, the Session layer handles session setup (which is like dialing a phone), session
maintenance (which is like having a phone conversation), and session termination, or teardown (which
is like ending a phone conversation and then hanging up the phone).
Presentation layer: This layer converts data for network delivery. The assumption that drives this
activity is that the sender and the receiver may not share a common set of data types, formats, or
representations. Therefore, the Presentation layer converts data from formats created by the sender
into a generic format for network transit, and then converts that generic form into a format specific to
the receiver upon delivery. This conversion process allows programmers on both sides of the network
connection to assume generic formats for network data, and to handle the details necessary to deliver
that data to a specific client more easily.
Application layer: This layer's name is something of a misnomer. It doesn't refer to the application or
service that seeks to send or receive data across a network. Rather, it refers to an interface between
the protocol stack and applications or system services. The Application layer defines the methods by
which applications or system services can request network access and by which they can obtain
access to incoming data from the network.
1. Fully integrated security system with the help of Kerberos.
2. Easy administration using group policy.
3. Scalable to any size n/w
4. Flexible (install/uninstall)
5. Extensible (modify the schema) New features in Server 2003
6. Rename computer name & Domain names.
7. Cross –forest trust relationship.
8. Site-to-Site replication is faster.
The way the paired wires are connected to the connector (RJ45) is different in cross cable and normal LAN cable. The theoretical length is 100 meters but after 80 meters you may see drop in speed due to loss of signal.
Message 1
Type: Error
Source: NTDS Replication
Category: DS RPC Client
Event ID: 2087
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: ComputerName
Description:
Active Directory could not resolve the following DNS host name of the source domain controller to an IP address. This error prevents additions, deletions and changes in Active Directory from replicating between one or more domain controllers in the forest. Security groups, group policy, users and computers and their passwords will be inconsistent between domain controllers until this error is resolved, potentially affecting logon authentication and access to network resources.
Source domain controller: DomainControllerName
Failing DNS host name: GUID._msdcs.DNSDomainName
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1:
1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\" or "ping ".
3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns
dcdiag /test:dns
4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
dcdiag /test:dns
5) For further analysis of DNS error failures see KB 824449: http://support.microsoft.com/?kbid=824449
Additional Data
Error value:
11004 The requested name is valid, but no data of the requested type was found.
Message 2
Type: Warning
Source: NTDS Replication
Category: DS RPC Client
Event ID: 2088
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: ComputerName
Description:
Active Directory could not use DNS to resolve the IP address of the source domain controller listed below. To maintain the consistency of Security groups, group policy, users and computers and their passwords, Active Directory successfully replicated using the NetBIOS or fully qualified computer name of the source domain controller.
Invalid DNS configuration may be affecting other essential operations on member computers, domain controllers or application servers in this Active Directory forest, including logon authentication or access to network resources.
You should immediately resolve this DNS configuration error so that this domain controller can resolve the IP address of the source domain controller using DNS.
Alternate server name: AlternateServerName
Failing DNS host name: GUID._msdcs.DNSDomainName
NOTE: By default, only up to 10 DNS failures are shown for any given 12 hour period, even if more than 10 failures occur. To log all individual failure events, set the following diagnostics registry value to 1:
1) If the source domain controller is no longer functioning or its operating system has been reinstalled with a different computer name or NTDSDSA object GUID, remove the source domain controller's metadata with ntdsutil.exe, using the steps outlined in MSKB article 216498.
2) Confirm that the source domain controller is running Active directory and is accessible on the network by typing "net view \\" or "ping ".
3) Verify that the source domain controller is using a valid DNS server for DNS services, and that the source domain controller's host record and CNAME record are correctly registered, using the DNS Enhanced version of DCDIAG.EXE available on http://www.microsoft.com/dns
dcdiag /test:dns
4) Verify that that this destination domain controller is using a valid DNS server for DNS services, by running the DNS Enhanced version of DCDIAG.EXE command on the console of the destination domain controller, as follows:
dcdiag /test:dns
5) For further analysis of DNS error failures see KB 824449: http://support.microsoft.com/?kbid=824449
Additional Data
Error value:
11004 The requested name is valid, but no data of the requested type was found.
Event ID 2087 occurs when Active Directory replication has failed because of a DNS or a NetBIOS lookup failure. Specifically, the domain controller that logged event ID 2087 was not able to resolve a replication partner's IP address by using one of the following: • The CNAME resource record
• The fully qualified computer name in DNS
• The NetBIOS computer name
Because the domain controller that logs the event cannot perform inbound replication, Active Directory data may be inconsistent among domain controllers. For example, user and computer group information may be inconsistent.
Event ID 2088 occurs when the following conditions are true: • Active Directory replication cannot resolve the replication partner’s CNAME resource record to an IP address by using DNS.
• Active Directory can resolve the replication partner’s IP address by using the partner's fully qualified computer name in DNS or by using the partner's NetBIOS computer name in a WINS or in a NetBIOS broadcast.
Note Even if NetBIOS name resolution succeeds, all DNS name resolution failures must be investigated and resolved, as DNS configuration errors can cause Active Directory functions to fail.
Back to the top
CAUSE
DNS lookup problems may cause Active Directory replication to fail in one of the following ways: • Case 1: A domain controller tries to replicate with another domain controller that is offline, and Active Directory and DNS data for the offline domain controller has not been updated or deleted to indicate that the domain controller is inaccessible.
• Case 2: A domain controller tries to replicate with another domain controller that is online, but because of DNS or networking issues, the domain controllers cannot locate each other.
All domain controllers register SRV, A, and CNAME records in DNS. The CNAME record is of the form Dsa_Guid._msdcs.Dns_Domain_Name. Dsa_Guid is the GUID of the directory system agent (DSA) object for the domain controller. Dns_Domain_Name is the name of the forest where the domain controller is located. Domain controllers require the CNAME record to locate and to identify their replication partners.
The Net Logon service on the domain controller registers all the SRV records. The DNS Client service on the domain controller registers the DNS host (A) record and the GUID CNAME record.
A domain controller uses the following steps to locate its replication partner: 1. The domain controller uses DNS to look for the CNAME record of its replication partner.
2. If the lookup is unsuccessful, the domain controller looks for the DNS A record of its replication partner. For example, the domain controller looks for dc-03.corp.contoso.com.
3. If the DNS A record lookup is unsuccessful, the domain controller performs a NetBIOS broadcast by using the host name of its replication partner. For example, the domain controller uses dc-03.
Back to the top
RESOLUTION
Case 1
To remove Active Directory and DNS data that is left behind by a domain controller that is no longer in use, follow the procedure in the following Microsoft Knowledge Base article:
216498 How to remove data in Active Directory after an unsuccessful domain controller demotion
If the domain controller must be online, resolve the blocking issue, and then put the domain controller back online. When you restart the domain controller, you automatically register Active Directory and DNS data that is required for Active Directory replication with the destination domain controller.
If you do not want to restart the domain controller, but you want to reregister its DNS records, go to step 7, "Register Resource Records in DNS."
Case 2
If replication does not occur because a destination domain controller cannot resolve the DNS name of a replication partner, you must diagnose DNS and network connectivity problems to determine the source of the failure.
To diagnose and to fix DNS support for Active Directory replication, follow these steps:1. Gather information.
You must have the following information to diagnose and to fix DNS support for Active Directory replication and other operations that depend on DNS: • The fully qualified domain name (FQDN) and IP address of the source domain controller.
• The FQDN and IP address of the DNS server that hosts the DNS zone for the Active Directory domain name.
Note Domain controller and DNS server information may be the same if the domain controller is also running the DNS Server service that hosts the DNS zone for the Active Directory domain name.
2. Verify network connection settings.a. On the domain controller that is reporting the error, click Network Connections in Control Panel.
b. Right-click the network connection that you want to configure, and then click Properties.
c. On the General tab for a local area connection or on the Networking tab for all other connections, click Internet Protocol (TCP/IP), and then click Properties.
d. In Use the following DNS server addresses, verify that the preferred DNS server or the alternate DNS server have the correct IP address of the DNS server that hosts the DNS zone for the Active Directory domain name.
Note We recommend that the preferred DNS server for the domain controller is located in a hub site that is local or well-connected. If you use such a hub site, you reduce replication latency.
e. If the IP addresses are correct, go to step 3. If the IP address is incorrect, enter the correct address, and then go to step 7.
3. Verify connectivity.
To verify connectivity, use the ping command on the destination domain controller to find the IP addresses of the source domain controller and of the DNS server.
On the destination domain controller, type the following at a command prompt, and then press ENTER after each command:
If either command is unsuccessful, a network connectivity error may exist. Contact the network administrator to diagnose and to fix this error. If both commands are successful, the error exists in DNS.
4. Verify that the DNS Server service is running.
If the destination domain controller is configured to use a local DNS server, verify that the DNS Server service is running. To do this, type net start “DNS Server” at a command prompt, and then press ENTER.
If the DNS Server service is running, a message appears that indicates that the service is running. If the DNS Server service is installed, but the service is not running, the command starts the DNS Server service.
If the DNS Server service is not installed, a message appears that indicates that the server name is not valid. If the destination domain controller is configured to use a remote DNS server, use the DNS console to start the DNS Server service. To do this, follow these steps: a. Open the DNS console.
b. On the Action menu, click Connect To DNS Server.
c. In Connect to DNS Server, click The following computer.
d. To connect to a remote server, specify either the remote server's DNS computer name or its IP address.
e. Click to select the Connect to the specified computer now check box, and then click OK.
f. On the Action menu, point to All Tasks, and then click Start.
5. Verify that the resource record is registered.
The destination domain controller uses the DNS CNAME resource record, Dsa_Guid._msdcs.Dns_Domain_Name, to locate its source domain controller replication partner. To verify that this resource record is in the DNS zone for the Active Directory domain name, follow these steps: a. Open the DNS console in the console tree. Locate any domain controller that is running the DNS Server service, where the service hosts the DNS zone with the same name as the Active Directory domain name.
b. In the console tree, click the zone that is named _msdcs.Dns_Domain_Name.
In Windows 2000 Server DNS, _msdcs.Dns_Domain_Name is a subdomain of the DNS zone for the Active Directory domain name. In Windows Server 2003, _msdcs.Dns_Domain_Name is a separate zone.
The zone that is named _msdcs.Dns_Domain_Name must contain the following:• A CNAME resource record that is named Dsa_Guid._msdcs.Dns_Domain_Name.
• A corresponding A resource record for the name of the DNS server that is identified as the target host in the CNAME record.
If the resource records do not exist, go to step 6 to diagnose why the Net Logon service did not register the resource records automatically.
6. Verify that the DNS Server service that hosts the zone for the Active Directory domain name is configured to accept dynamic updates. a. In the DNS console, right-click the applicable zone, and then click Properties.
b. On the General tab, verify that the zone type is Active Directory–integrated.
c. In Dynamic Updates, click secure only. (In Windows 2000 Server, the secure dynamic update option is named Only secure updates.)
7. Register DNS resource records in DNS.
The Net Logon service on a domain controller registers the DNS resource records that are required for the domain controller to be located in the network. To manually initiate this registration on the source domain controller, type the following at a command prompt, and then press ENTER after each command:
net stop "net logon"
net start "net logon"
The DNS Client service registers the host (A) resource record that the CNAME record points to. To initiate this registration on the source domain controller, type ipconfig /registerdns at a command prompt, and then press ENTER.
8. Verify resource record registration.
To verify that the records were registered successfully, go to step 5, “Verify that the resource record is registered."
9. Force replication on the source and destination domain controllers.a. On the destination domain controller, open Active Directory Sites and Services.
b. In the console tree, click NTDS Settings for the domain controller that you want to force replication on.
c. In the details pane, right-click the connection that you want to use to replicate directory information, and then click Replicate Now.
You can also use the repadmin and replmon command-line tools. These tools are available on your Windows Server 2003 installation CD. (The repadmin command is repadmin /syncall /d /e /P source_domain_controller.)
10. Investigate other problems.
If the previous steps do not resolve the errors, a domain controller may not be able to dynamically register its DNS resource records because the DNS servers that the domain controller uses for name resolution cannot find a primary authoritative zone for these resource records. In this case, there are two possible causes: • The preferred or alternate DNS servers that are used by the destination domain controller for name resolution contain incorrect root hints. For information about updating the root hints, visit the following Microsoft Web sites:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/7b69b6f9-f25e-4594-a04b-f08f3effa203.mspx
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/3e3d2262-518f-4e97-a5cb-737ed52d2cd9.mspx
• There are incorrect delegations in the DNS zones. These delegations start at the root and descend to the zone with the same name as the Active Directory domain name. For information about verifying the zone delegations, visit the following Microsoft Web site:
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/977fa8ed-ec71-4d39-9f9e-9facd5a61364.mspx
.
Set account, audit and password policies
Set user rights
Permissions or policies Pertains only to the DC where you set.
Domain security policy:
Set account, audit and password policies
Set user rights
Permissions or policies pertain to the DC as well as to all the domains within.
Windows 2003 O.S.
A static IP
NTFS partition with 250 MB of free HDD space
DNS (Domain Naming System)
Step1: on 2003 machine
Start > Run> dcpromo>next>next
>Select domain controller for a new domain
>Domain in a new forest >next
>Specify the domain name (Ex: zoom.com)
>Net bios name (do nothing)>Next
>database>next
>Sysvol>next
>Select middle one>next
>Provide pwd>next
>Restart - when it prompts
After installing A.D.
Go to
Start>programs> administration tools
We should notice 5 options like ADUC, ADDT, ADSS, DCSP, and DSP
