Find domain name from command line

We can find the domain name of a computer by running the following commnad from command line.

We can find the logged in user’s domain by using the environment variable ‘USERDOMAIN’. Command for this is given below.

Note that the value in %USERDOMAIN% may not be the same as the one returned by systeminfo command. %USERDOMAIN% gives the domain name the user account belongs to, it could be different from the domain of the computer. Also, this may give you the NetBios name of the computer, not DNS/FQDN name.

Alternatively, we can use WMIC to retrieve domain name.

Whatt is the command to view domain name in windows 7

All the above commands work on Windows 7. WMIC one may/may not work depending on whether the edition of win7 you have supports it or not.

The systeminfo command given in this post works on Windows 7 also. I think copying the command from this page had some problem and it did not work. Have corrected it. It should work now.

systeminfo | findstr Domain

I see no reason for the /b /c:” “

/C may not be required. /b is required to avoid matches with the values for other fields of systeminfo command.

Thanks! Useful!! Keep it up your good work.

Thanks for this! I needed to pull the domain for a powershell script for use on servers that didn’t have the ActiveDirectory module (and I wasn’t going to install it).

This enabled me to grab the domain, then trim out the header and return in Powershell for my variable.

This command returns domain or workgroup: net config workstation
* If domain: “Workstation Domain DNS Name”
* If group: “Workstation domain”

Get-WmiObject is not recognized as a command. Any help guys?

Get-WmiObject is a PowerShell cmdlet. You need to use the command in the PowerShell Terminal. To do it in the CMD Terminal, you need to run the WMIC commands (as explained above)
For example, “wmic computersystem get domain” (without quotes)

Can someone please guide me on how to obtain the domain name of the servers remotely. I need to get the domain name for hunderds of servers.
Is there a way to create a CSV file with the server names and create a batch file and run it to obtain this information?
Any help would be highly appreciated.
Thanks.

wmic /node:”COMPUTERNAME” computersystem get domain

I am getting domain as workgroup. what’s wrong here?

It means that your computer is not part of a domain but a workgroup. All the home computers are part of a workgroup.

what is domain for windows 8? i need it for change to administrator, it is will work?

thanks for share me the value knowledge

Excellent info and list of commands.. Thank you.

Just type –> set user

gives you the domain info without searching

set user only shows the domain of which the user is a member.
NOT the computer’s domain. (This could be different).

If so, the ‘wmic computersystem get domain’ is a working command.

systeminfo | findstr /B /C:”Domain” depends on the OS language.
if you have a german OS, it’s
systeminfo | findstr /B /C:”Domäne” .
But otherwise fine info.

How to configure DFS to use fully qualified domain names in referrals

This article describes how to configure a DFSN server to operate in that environment.

Original product version: В Windows Server 2012 R2
Original KB number: В 244380

Summary

By default, a Microsoft Distributed File System Namespace (DFSN) root referral reply to a DFS root referral query is in NetBIOS name format ( \\ \ ). It’s necessary in certain environments that rely on NetBIOS and makes it possible for clients that support NetBIOS-only name resolution to locate and connect to targets in the DFS namespace. By default, Windows clients work fine with it.

However, some clients don’t use NetBIOS. Two examples are clients that aren’t running Windows and clients that operate in an environment without WINS or that use DNS name suffixes. Those clients are incompatible with the default DFSN behavior.

In these cases, the client may be unable to resolve the server name that is returned from the root referral query. However, this problem can be addressed easily, because DFSN can be configured to operate in a DNS-only environment.

For namespace servers that are hosting only stand-alone namespaces, some steps that are described in this article are unnecessary. (Such namespace servers include clustered namespaces.) By default, DFSN clients can access such stand-alone namespaces through either \\ \\ or \\ \\ namespace paths. However, namespace server configuration is still required for stand-alone namespaces in order to provide correct referrals.

The steps that are described in this article apply to all DFS namespace servers, regardless of whether such namespace servers also act as Active Directory domain controllers.

Four stages

The overall approach consists of the following four stages:

1. Configure a DNS suffix for resolution of qualified names on the client.
2. Verify DNS records of file server targets, and create host records as required.
3. Configure the DFSN server to respond by using FQDN referrals for root targets.
4. If it’s required, update the namespace metadata for each folder target so that the folder referrals use appropriate FQDN names for folder targets.

Steps for stage 3: Configure the DFSN server to respond by using FQDN referrals for root targets

Before you continue with the following steps for stage 3, we recommend that you back up the namespace metadata to guard against unexpected failures or accidents. The backup steps, together with the other restore steps if you ever need them, are covered in steps A and C of the Steps for stage 4 section.

The DFSN Windows PowerShell cmdlets that are mentioned in this section are available only starting with Windows Server 2012 or Windows 8.

Obtain the list of domain-based namespaces that are hosted on the server. To do it, use one of the following methods:

If there are no domain-based namespaces that are hosted on this namespace server, you don’t have to follow some steps in this article.

You can skip the following step for namespace servers that host only stand-alone namespaces.

Generally, domain-based namespaces are hosted on multiple namespace servers. So when you remove the namespace from one namespace server, as you do in this step, namespace availability isn’t affected. However, you should make sure that there is in fact more than one namespace server that is hosting your namespace. To do it, use one of the following methods:

For example, the placeholder could represent the following:
\\contoso.com\DomainNamespace If you confirm that there are multiple namespace servers hosting your namespace, you can skip step C that follows.

You can skip the following step for namespace servers that host only stand-alone namespaces. You can also skip this step if you confirm that there are multiple namespace servers that are hosting your namespace.

If there’s only one namespace server for your namespace, you should temporarily add a new namespace server before you remove the existing server. (See Add Namespace Servers to a Domain-based DFS Namespace or New-DfsnRootTarget cmdlet.) Or, you must save the namespace metadata for a re-creation later. (To do it, see steps A and C of the Steps for stage 4 section.) However, you should be aware that the second approach will cause a transient downtime for the namespace.

You can skip the following step for namespace servers that host only stand-alone namespaces.

Remove each hosted domain-based namespace from the server. To do it, use one of the following methods:

For example, the placeholder could represent the following:
\\Contoso-FS.contoso.com\AccountingSoftware

Enable the DFSN FQDN root referral behavior. To do it, use one of the following methods:

Restart the DFSN service. To do it, use one of the following methods:

You can skip the following step for namespace servers that are hosting only stand-alone namespaces.

Restore each namespace that you previously removed from this namespace server. To do this, use one of the following methods:

Depending on what you did in step B, follow these optional steps:

1. If you took a backup of your namespace metadata in step B, you can import the metadata into the namespace that you just re-created. Before you import the metadata, you can also make any necessary adjustments as part of the same step. (See the Steps for stage 4 section.)
2. If you temporarily added a namespace server in step B, you may remove it now.

Steps for stage 4: Update the namespace metadata for each folder target so that the metadata uses appropriate FQDN names

Follow these steps for each namespace that is hosted on the namespace server:

Export the namespace metadata:

Make any necessary FQDN-related adjustments to folder targets. For each «Target» XML element that is contained in a «Link» XML element, change its NetBIOS reference to its equivalent FQDN reference.

For example, before the update, the element is as follows:

After the update, the element is as follows:

Import the updated namespace metadata:

References

For more information about related topics, see:

Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003

This article describes best practices for the configuration of Domain Name System (DNS) client settings. The recommendations in this article are for the installation of Windows 2000 Server or Windows Server 2003 environments where there is no previously defined DNS infrastructure.

Original product version: В Windows Server 2012 R2
Original KB number: В 825036

Domain controller with DNS installed

On a domain controller that also acts as a DNS server, Microsoft recommends that you configure the domain controller’s DNS client settings according to these specifications:

If the server is the first and only domain controller that you install in the domain, and the server runs DNS, configure the DNS client settings to point to that first server’s IP address. For example, you must configure the DNS client settings to point to itself. Do not list any other DNS servers until you have another domain controller hosting DNS in that domain.

During the DCPromo process, you must configure additional domain controllers to point to another domain controller that is running DNS in their domain and site, and that hosts the namespace of the domain in which the new domain controller is installed. or if using a 3rd-party DNS to a DNS server that hosts the zone for that DC’s Active Directory domain. Do not configure the domain controller to utilize its own DNS service for name resolution until you have verified that both inbound and outbound Active Directory replication is functioning and up to date. Failure to do so may result in DNS «Islands».
For more information about a related topic, click the following article number to view the article in the Microsoft Knowledge Base:

275278 DNS Server becomes an island when a domain controller points to itself for the _msdcs.ForestDnsName domain

After you’ve verified that replication has completed successfully, DNS may be configured on each Domain Controller in either of two ways, depending on the requirements of the environment. The configuration options are:

• Configure the Preferred DNS server in TCP/IP properties on each Domain Controller to use itself as Primary DNS Server.
  • Advantages: Ensures that DNS queries originating from the Domain Controller will be resolved locally if possible. Will minimize impact of Domain Controller’s DNS queries on the network.
  • Disadvantages: Dependent on Active Directory replication to ensure that DNS zone is up to date. Lengthy replication failures may result in an incomplete set of entries in the zone.
• Configure all Domain Controllers to use a centralized DNS server as their Preferred DNS Server.
  • Advantages:
    • Minimizes the reliance on Active Directory replication for DNS zone updates of Domain Controller locator records. It includes faster discovery of new or updated Domain Controller locator records, as replication lag time isn’t an issue.
    • Provides a single authoritative DNS server, which may be useful when troubleshooting Active Directory replication issues
  • Disadvantages:
    • Will more heavily use the network to resolve DNS queries originating from the Domain Controller
    • DNS name resolution may depend on network stability. Loss of connectivity to the Preferred DNS server will result in failure to resolve DNS queries from the Domain Controller. It may result in apparent loss of connectivity, even to locations that aren’t across the lost network segment.

A combination of the two strategies is possible, with the remote DNS server set as Preferred DNS server, and the local Domain Controller set as Alternate (or vice versa). While this strategy has many advantages, there are factors that should be considered before making this configuration change:

• The DNS client does not utilize each of the DNS servers listed in TCP/IP configuration for each query. By default, on startup the DNS client will attempt to use the server in the Preferred DNS server entry. If this server fails to respond for any reason, the DNS client will switch to the server listed in the alternate DNS server entry. The DNS client will continue to use this alternate DNS server until:
  • It fails to respond to a DNS query, or:
  • The ServerPriorityTimeLimit value is reached (15 minutes by default).

Only a failure to respond will cause the DNS client to switch Preferred DNS servers; receiving an authoritative but incorrect response does not cause the DNS client to try another server. As a result, configuring a Domain Controller with itself and another DNS server as Preferred and Alternate servers helps to ensure that a response is received, but it does not guarantee accuracy of that response. DNS record update failures on either of the servers may result in an inconsistent name resolution experience.

• Don’t configure the DNS client settings on the domain controllers to point to DNS servers of your Internet Service Provider (ISP). If you configure the DNS client settings to point to your ISP’s DNS servers, the Netlogon service on the domain controllers doesn’t register the correct records for the Active Directory directory service. With these records, other domain controllers and computers can find Active Directory-related information. The domain controller must register its records with its own DNS server.

To forward external DNS requests, add the ISP’s DNS servers as DNS forwarders in the DNS management console. If you don’t configure forwarders, use the default root hints servers. In both cases, if you want the internal DNS server to forward to an Internet DNS server, you also must delete the root «.» (also known as «dot») zone in the DNS management console in the Forward Lookup Zones folder.

• If the domain controller that hosts DNS has several network adapters installed, you must disable one adapter for DNS name registration.

For more information about how to configure DNS correctly in this situation, click the following article number to view the article in the Microsoft Knowledge Base:

292822 Name resolution and connectivity issues on a Routing and Remote Access Server that also runs DNS or WINS

To verify your domain controller’s DNS client settings, type the following command at a command prompt to view the details of your Internet Protocol (IP) configuration: ipconfig /all
To modify the domain controller’s DNS client configuration, follow these steps:

Right-click My Network Places, and then select Properties.

Right-click Local Area Connection, and then select Properties.

Select Internet Protocol (TCP/IP), and then select Properties.

Select Advanced, and then select the DNS tab. To configure the DNS information, follow these steps:

1. In the DNS server addresses, in order of use box, add the recommended DNS server addresses.
2. If the For resolution of unqualified names setting is set to Append these DNS suffixes (in order), Microsoft recommends that you list the Active Directory DNS domain name first (at the top).
3. Verify that the DNS Suffix for this connection setting is the same as the Active Directory domain name.
4. Verify that the Register this connection’s addresses in DNS check box is selected.
5. Select OK three times.

If you change any DNS client settings, you must clear the DNS resolver cache and register the DNS resource records. To clear the DNS resolver cache, type the following command at a command prompt: ipconfig /flushdns
To register the DNS resource records, type the following command at a command prompt: ipconfig /registerdns

To confirm that the DNS records are correct in the DNS database, start the DNS management console. There should be a host record for the computer name. (This host record is an «A» record in Advanced view.) There also should be a Start of Authority (SOA) record and a Name Server (NS) record that points to the domain controller.

Domain controller without DNS installed

If you do not use Active Directory-integrated DNS, and you have domain controllers that do not have DNS installed, Microsoft recommends that you configure the DNS client settings according to these specifications:

• Configure the DNS client settings on the domain controller to point to a DNS server that’s authoritative for the zone that corresponds to the domain where the computer is a member. A local primary and secondary DNS server is preferred because of Wide Area Network (WAN) traffic considerations.
• If there’s no local DNS server available, point to a DNS server that’s reachable by a reliable WAN link. Up-time and bandwidth determine reliability.
• Don’t configure the DNS client settings on the domain controllers to point to your ISP’s DNS servers. Instead, the internal DNS server should forward to the ISP’s DNS servers to resolve external names.

Windows 2000 Server and Windows Server 2003 member servers

On Windows 2000 Server and Windows Server 2003 member servers, Microsoft recommends that you configure the DNS client settings according to these specifications:

• Configure the primary and secondary DNS client settings to point to local primary and secondary DNS servers (if local DNS servers are available) that host the DNS zone for the computer’s Active Directory domain.
• If there are no local DNS servers available, point to a DNS server for that computer’s Active Directory domain that can be reached through a reliable WAN link. Up-time and bandwidth determine reliability.
• Don’t configure the client DNS settings to point to your ISP’s DNS servers. If you do so, you may experience issues when you try to join the Windows 2000-based or Windows Server 2003-based server to the domain, or when you try to log on to the domain from that computer. Instead, the internal DNS server should forward to the ISP’s DNS servers to resolve external names.