With the native NET command:
NET USER loginname /DOMAIN | FIND /I " name "
With (native) Windows Server 2003 commands:
DSQUERY USER -samid *loginname* | DSGET USER -samid -display| Note: | The NET command may seem more universal, because it requires neither Active Directory nor Windows Server 2003 commands, but it is language dependent! For non-English Windows you may need to modify FIND's search string. |
In Windows NT 4 and later, users usually are members of global groups. These global groups in turn are members of (domain) local groups. Access permissions are given to (domain) local groups.
To check if a user has access to a resource, we need to check group membership recursively.
With (native) Windows Server 2003 commands:
DSQUERY USER -samid loginname | DSGET USER -memberof -expand
My collegues often forget to mention their logon account name when calling the helpdesk, and the helpdesk doesn't always ask either. I suppose they expect me to know all 1500+ accounts by heart.
With (native) Windows Server 2003 commands only:
DSQUERY USER -name *lastname* | DSGET USER -samid -display| Note: | Windows Server 2003's "DSTools" will work fine in Windows 2000 and XP too, when copied. Keep in mind, however, that some Windows Server 2003 Active Directory functionality is not available in Windows 2000 Active Directories. |
We often need to know who is currently logged on to a remote computer.
With native Windows commands only:
NBTSTAT -a remotecomputer | FIND "<03>" | FIND /I /V "remotecomputer"The first name in the list usually is the logged on user (try playing with the NET NAME command to learn more about the names displayed by NBTSTAT).
This is the fastest way to find the logged on user name, and the results that you do get are correct, but NBTSTAT won't always return a user name, even when a user is logged on.
Using WMIC (Windows XP Professional and later):
WMIC /Node:remotecomputer ComputerSystem Get UserNameThis is arguably the most reliable (native) command to find out who is logged on.
With the help of SysInternals' PSTools:
PSLOGGEDON -L \\remotecomputeror:
PSEXEC \\remotecomputer NET CONFIG WORKSTATION | FIND /I " name "or:
PSEXEC \\remotecomputer NET NAMEor:
PSEXEC \\remotecomputer NETSH DIAG SHOW COMPUTER /V | FIND /i "username"or:
FOR /F %%A IN ('REG Query \\remotecomputer\HKU ˆ| FINDSTR /R /B /C:"HKEY_USERS\\S-1-5-[0-9][0-9]-[0-9-]*$"') DO (
FOR /F "tokens=3 delims=\" %%B IN ('REG Query "\\remotecomputer\%%A\Volatile Environment"') DO (
SET LoggedinUser=%%B
)
)NETSH and WMIC are for XP or later, and are the most reliable of all commands shown here.WMIC requires WMI enabled remote computers and Windows XP on the administrator's computer; NETSH requires Windows XP on the remote computers.
PSLOGGEDON is a more accurate solution than NBTSTAT, but it will return the last logged on user if no one is currently logged on.
The NET and NBTSTAT commands show more or less identical results, but the NBTSTAT command is much faster.
The REG command is accurate, but may need to be modified depending on the version used. As displayed here, the code is written for REG.EXE 3.0 (XP).
If you want to search lots of computers for logged on users, I recommend you try NBTSTAT first (fast, but it won't always return the user name!), and only switch to NETSH, REG or WMIC (accurate) if NBTSTAT doesn't return a user name.
Credits: Jiří Janyška (WMIC command) and Matthew W. Helton (NETSH command).
Sometimes we may need to know how many users are logged on to a (file) server, like maybe when there is a performance degradation.
At the server's console itself, with native commands only:
NET SESSION | FIND /C "\\"Remotely, with the help of SysInternals' PSTools:
PSEXEC \\servername NET SESSION | FIND /C "\\"By replacing FIND /C "\\" by FIND "\\" (removing the /C switch) you'll get a list of logged on users instead of just the number of users.
It is important to back up your domain controllers to ensure their availability. Backing up a domain controller is like backing up a Microsoft® Exchange member server. The primary difference between backing up a domain controller and backing up an Exchange member server is that you do not have Exchange databases to consider when you back up a domain controller. The method that you use to back up your domain controller depends on the disaster recovery strategy you choose.
Backing Up the System State Data of a Domain Controller When you use Backup to back up the System State data of a domain controller, you also back up the Active Directory® directory service database. To back up the System State data of a domain controller that is running Active Directory, you can use the same procedure as you would for a server that is not a domain controller. However, you must also back up additional files, such as the Active Directory database and log files, and all other files for the system components and services on which Active Directory depends.
The following Active Directory files are part of a System State data backup of a domain controller. By default, these files are located in the Active Directory folder in %SystemRoot%\Ntds.
| File type | Definition |
|---|---|
| Ntds.dit | The Active Directory database. |
| Edb.chk | The checkpoint file. |
| Edb*.log | The transaction log files; each file is 10 megabytes (MB). |
| Res1.log and Res2.log | The reserved transaction log files. |
In addition to the System State data, you must also back up the Microsoft Windows® boot partition and system partition when you perform either a Windows backup or a full computer backup of a domain controller.
Circular logging for Active Directory is enabled on domain controllers and cannot be turned off. If you lose all your domain controllers to a disaster and must restore a backup of Active Directory, you will lose data that was written to Active Directory after the backup set was made. Therefore, make regular backups of Active Directory. It is recommended that you back up one domain controller nightly.
Recommendations for Backing Up a Domain Controller Consider the following recommendations before you back up a domain controller:
