How to find the DNS Name of a domain


The following knowledgebase will tell you the procedure you can use to retrieve the DNS name of a domain from registry.

The following registry location is the best place to find the DNS name of a domain controller.

HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History.

In the right pane, you will see an entry by name DCName=

The above entry will contain the DNS name of the domain. This DNS name of domain is stored in registry key after Winlogon retrieves the Domain controller by using the DcGetDCName API call.

Advertisements

How To Check What All Programs Will Run When User Logged On To Computer.


The following knowledgebase will tell you how you can check what all programs will run when user has logged on to the computer.

When user logs on to the computer the Winlogon service will use the following registry entry to run any programs (if specified):

HKLM\Software\Micrsofot\Windows\CurrentVersion\Run

HKLM\Software\Micrsofot\Windows\CurrentVersion\RunOnce

The above two registry entries are used by Winlogon service after user has logged on to the system successfully. The Winlogon service will create a list of programs to run.

Please note that domain policy may override this setting if specified. You can also use Group Policy settings to block any program to run.

You can use the following script to check the programs in Run or RunOnce registry key on remote computer.

*** Start ***

@echo off

Set RegQry=HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Set RegQry1=HKLM\Software\Microsoft\Windows\CurrentVersion\RunOnce

REG.exe Query \\remote_computer\%RegQry% > CheckRun.txt

REG.exe Query \\remote_computer\%RegQry1% > CheckRunOnce.txt

Echo Programs on Computer : Remote_Computer >> Programs.txt

For /F “Skip=5 Tokens=*” %%a In (CheckRun.txt) Do (

Echo %%a >> Programs.txt

)

For /F “Skip=5 Tokens=*” %%a In (CheckRunOnce.txt) Do (

Echo %%a >> Programs.txt

)

*** End ***

You can use PSEXEC (a tool from Sysinternals) to run this script remotely and then redirect the output in a Text file.

How To Check Crash Control Settings On Remote Computer


The following knowledgebase will explain the methods you can use to set the Crash Control (Memory dump) on remote computers.

You can use the following methods to check and set the Crash Control settings on remote computer:

  1. Connecting to Remote Registry Service
  2. Using a script

The first method is easy but includes a lot of efforts. You can navigate to the following location in registry after connecting to remote registry:

HKLM\SYSTEM\CurrentControlSet\Control\CrashControl

The above registry includes the following values in right pane:

AutoReboot DWORD 00000001

CrashDumpEnabled DWORD 00000003

DumpFile STRING The dump file name

LogEvent DWORD 00000001

MinidumpDir DWORD The dump file location

Overwrite DWORD 00000001

SendAlert DWORD 00000001

You can use the below script to check the Crash Control settings on a remote computer is enabled or not.

@echo off

Srvlist=C:\Temp\Srvlist.txt

Echo Computer Name, Crash Control Settings Enabled?, Auto Reboot? >> Result.csv

SET Crash_Ctrl=

SET Auto_Rbt=

For /F “Tokens=*” %%a In (%srvlist%) Do (

Set Comp_name=%%a

Set RegQry=”\\%%a\HKLM\SYSTEM\CurrentControlSet\Control\CrashControl”

REG.exe Query %RegQry% > CheckCC.txt

Find /i “CrashDumpEnabled REG_DWORD 0x3” < CheckCC.txt > StringCheck.txt

If %errorlelvel% == 0 (

SET Crash_Ctrl=Enabled

) ELSE (

SET Crash_Ctrl=Disabled

)

Find /i “AutoReboot REG_DWORD 0x1” < CheckCC.txt > StringCheck.txt

If %errorlelvel% == 0 (

SET Auto_Rbt=Enabled

) ELSE (

SET Auto_Rbt=Disabled

)

Echo %Comp_name, %Crash_Ctrl%, %Auto_Rbt% >> Result.csv

)

*** End ***

How to verify the Page File location through a script:


The following knowledgebase will explain the methods you can use to check the Location of Page File on local and remote computer.

To check on local computer:

You can use the following methods:

  1. Connecting to Remote Registry Service
  2. Using a script

The first method is easy but includes a lot of efforts. You can navigate to the following location in registry after connecting to remote registry:

HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management

 

The above registry key includes the following values in right pane:

pagingfiles REG_MULTI_SZ c:\pagefile.sys 3131 3131

 

To check on a Remote Computer:

You can use the below script to check the Paging File location on a remote computer:

@echo off

Srvlist=C:\Temp\Srvlist.txt

Echo Computer Name, Paging File Location >> Result.csv

SET PF_Loc=

For /F “Tokens=*” %%a In (%srvlist%) Do (

Set Comp_name=%%a

Set RegQry=”\\%%a\HKLM\system\currentcontrolset\control\session manager\Memory management /v pagingfiles

REG.exe Query %RegQry% > CheckCC.txt

FOR /f “Tokens=3” %%b in (CheckCC.txt) Do SET PF_Loc=%%b

Echo %Comp_name, %PF_Loc% >> Result.csv

)

The above script will check remote computer for one registry entry for Paging File location and the results will be saved in a CSV format file.

How to check and set Default Home Page URL using a script


The following knowledgebase will explain the methods you can use to check the Default Home Page URL on local and remote computer.

To check on a local computer:

You can use the following methods:

  1. Connecting to Remote Registry Service
  2. Using a script

The first method is easy but includes a lot of efforts. You can navigate to the following location in registry after connecting to remote registry:

HKLM\Software\Microsoft\Internet Explorer\Main

The above registry includes the following values in right pane:

Default_Page_URL REG_SZ http://portal.csc.com/\

To check on a Remote Computer:

You can use the below script to check the Default Home Page URL on a remote computer:

@echo off

Srvlist=C:\Temp\Srvlist.txt

Echo Computer Name, Default Home Page >> Result.csv

SET Default_URL=

For /F “Tokens=*” %%a In (%srvlist%) Do (

Set Comp_name=%%a

Set RegQry=”\\%%a\HKLM\Software\Microsoft\Internet Explorer\Main” /v Default_Page_URL

REG.exe Query %RegQry% > CheckCC.txt

Find /i “Default_Page_URL” < CheckCC.txt > StringCheck.txt

FOR /f “Tokens=3” %%b in (CheckCC.txt) DO SET Default_URL=%%b

Echo %Comp_name, %Default_URL% >> Result.csv

)

The above script will check remote computer for one registry entry for checking Default Home Page URL and the results will be saved in a CSV format file.

How to refresh the Group Policy Settings on remote computers


The following knowledgebase explains the scenario in which you need to refresh the Group Policy Settings on a remote computer.

The Group Policy Settings are refreshed as per the interval configured in the Group Policy for client computers, member servers and domain controllers. You can use the following command line tools to refresh the Group Policy Settings on remote computer. You need to log on to the computer manually and then perform the action suggested below:

For Windows XP computers:

  • Gpupdate.exe /Target:User /force
  • Gpupdate.exe /Target:Computer /force

For Windows 2000 computers:

  • Secedit.exe /refreshpolicy user_policy
  • Secedit.exe /refreshpolicy machine_policy

To refresh the policy on remote computer or computers you can use the following script to do so:

  1. Create a ComputerList.txt
  2. Put all the remote computers in the Text file.
  3. Use the Psexec.exe tool to execute the command remotely.

For Windows XP Computers:

Psexec.exe -@ComputerList.txt Gpupdate.exe /Target:User /force

Psexec.exe -@ComputerList.txt Gpupdate.exe /Target:Computer /force

For Windows 2000 Computers:

Psexec.exe -@ComputerList.txt secedit.exe /refreshpolicy user_policy

Psexec.exe -@ComputerList.txt secedit.exe /refreshpolicy machine_policy

The above Psexec.exe command will run on all the computers specified in the ComputerList.txt.

You can also use the following script to check the version of Operating System and then issue the command:

@echo off

XPGPORef1=gpupdate.exe /Target:User /force

XPGPORef2=gpupdate.exe /Target:Computer /force

Win2kGPORef1=secedit.exe /refreshpolicy user_policy

Win2kGPORef2=secedit.exe /refreshpolicy machine_policy

For /f “Tokens=*” %%a in (ComputerList.txt) Do (

SET Comp_name=%%a

Ver.exe \\%comp_name% > Hostver.txt

Find /I “XP” < Hostver.txt > CheckCC.txt

IF %errorlevel% == 0 (

Psexec.exe \\%comp_name% Gpupdate.exe /Target:User /force

Psexec.exe \\%comp_name% Gpupdate.exe /Target:Computer /force

) ELSE (

Psexec.exe \\%comp_name% secedit.exe /refreshpolicy user_policy

Psexec.exe \\%comp_name% secedit.exe /refreshpolicy machine_policy

)

)

The above script will check the Operating System version by executing Ver.exe on remote computer and then run the appropriate commands to refresh the Group Policy Objects.

Posted by Nirmal

Troubleshooting Active Directory account lockout issues


AD/Exchange pro does often face an issue for which there is little documentation available on internet – User Account lockouts.

I know this, because I have been troubleshooting an account lockout issue for a while with minimal help. So, here we go – My guide for troubleshooting Active Directory account lockout issues

Before entering advanced troubleshooting mode we need to ensure we cover all the basics:

1. Exchange ActiveSync mobile devices

2. Apple MobileMe – contacts sync

3. Applications / Web applications/ Tools which sync with Active Directory for authentication

4. Vault for credentials in Windows Control Panel or Credential manager

5. Stored usernames and passwords – rundll32.exe keymgr.dll, KRShowKeyMgr

6. Rename AD Profile on the user machine

Let’s look at each in detail:

1. Exchange ActiveSync mobile devices – Yes EAS devices, EAS devices and EAS devices. 80% of account lockout issues are caused by an “unknown” device trying to sync with your Exchange mailbox and when you ask the user he would say – “What do you mean a mobile device – I already told ya”… J

DO NOT listen to the user:

In Exchange management Shell run this:

Get-ActiveSyncDeviceStatistics -Mailbox MeeraNair

This is going to return all the devices the user is using right now and past devices which have established connection with Exchange at least once.

FirstSyncTime : 5/3/2011 2:52:38 AM

LastPolicyUpdateTime : 3/8/2012 3:32:24 PM

LastSyncAttemptTime : 3/8/2012 6:11:53 PM

LastSuccessSync : 3/8/2012 6:11:53 PM

DeviceType : iPhone

DeviceID : Appl6DxxxxxxS

DeviceUserAgent : Apple-iPhone3C1/901.405

Identity : Meera.Nair@msexchangeguru.com\AirSync-iPhone-Appl6DxxxxxxS

FirstSyncTime : 7/7/2011 1:38:44 AM

LastPolicyUpdateTime : 3/8/2012 6:14:20 PM

LastSyncAttemptTime : 3/8/2012 7:34:09 PM

LastSuccessSync : 3/8/2012 7:34:09 PM

DeviceType : iPhone

DeviceID : Appl6QxxxxxxS

DeviceUserAgent : Apple-iPhone3C1/901.405

Identity : Meera.Nair@msexchangeguru.com\AirSync-iPhone-Appl6QxxxxxxS

Now, educate the user that these are the devices which are syncing with his mailbox and they have his username and password stored. So, look at the LastSyncAttemptTime and make sure it is not an EAS device which is trying to authenticate him.

1. Apple MobileMe – Contacts sync– Check and ensure the user hasn’t configured MobileMe to sync his contacts from Outlook. If this is configured with AD credentials, it can be a reason for account lockout

2. Applications / Web applications/ Tools which sync with Active Directory for authentication: You heard it right. There might be third party applications which are running which may have AD username and password stored within and lot of times the moment the user open applications like Internet explorer / browser, the application or the tools, it will try to authenticate in the background and lock the password.

3. Vault for credentials in Windows Control Panel or Credential manager: This is the second most obvious reason the user might get locked out. In my case, the user had an intranet SharePoint web portal and the AD credentials where cached in Credential manager. To open credential manager:

clip_image001

Make sure Windows Credentials area is empty

clip_image002

1. Stored usernames and passwords – This shouldn’t be a problem in most cases, but better safe than sorry. Open a run windows and type rundll32.exe keymgr.dll, KRShowKeyMgr and delete stored passwords if any

2. Rename AD Profile on the user machine: This is more like trying to fix the issue without knowing what’s causing it. This is under the assumption that account lockout happens when the user is logged into his client machine. If the account lockout is caused from an application or “something” from that machine, rename the AD profile on the client from “Documents and Settings in XP and Users in Win7″, advise the user to login again and monitor the situation.

Now let’s look at some advanced troubleshooting steps.

Using the Microsoft Lockout Status tool

1. Download Lockout Status tool from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18465 on to a New Folder in a client machine.

2. After extracting the downloaded file, you will have the files below:

clip_image003

1. Open LockOutStatus.exe and click File –> Select Target As –> Type the username and User Logon Name as Target User Name (the one which is getting locked out ) and click OK as indicated below:

clip_image004

clip_image005

Please ensure that the tool is running on any machine

1. This will then process the records through all the domain controllers. You can keep a close eye on the column Bad PWD Count.

2. If the account gets locked out frequently, the Bad Password count keeps increasing. Make a note of that GC which indicates a Bad PWD Count of any value more than 0. Also note that the same value will be indicated by the primary domain controller in the domain which can be ignored.

clip_image006In this case, I will login to DC01 and all the domain controllers in this site and set the following registry:

· Open regedit with an account that has necessary permissions and move to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

· Create a new DWORD Value with the name DBFlag and a Hexadecimal value 2080ffff.

1. Once this is set, restart Netlogon service on DC01 and then wait for the Account to lockout.

2. Once the account locks out, ensure that Domain controller that locked out the account again from LockoutStatus.exe and take the Netlogon.log file from C:\Windows\Debug.

3. Bring the Netlogon.log to the client machine which has the Lockout Status tool installed and open nlparse.exe from the Lockout Status Tools download.

Click File –> Open and Browse the Netlogon.log location

clip_image007

clip_image008

Once the file is browsed, chose the 2 status codes 0xC000006A and 0xC0000234 and click Extract.

clip_image009

Once the extraction is complete, it will indicate a Pop-Up as indicated below:

clip_image010

There will be 2 new files in the location of the Netlogon.log file in the Client machine – A new CSV and a summary output file.clip_image011

Open the CSV file and filter the User Alias for the recent lockout:

clip_image012

This indicates that DC01 received the lockout from DC07.

In this case, you can perform Steps 6 to 12 again on DC07 and check the machine that the lockout occurs from.

In my case, I found that DC07 was receiving the lockout from a Cisco Secure ACS Appliance which helped me find that the account was being locked out due to incorrect password to connect to Wi-Fi from a MAC Apple Device. With the help of an the MAC Address provided by the Team that managed the ACS Appliance, we identified that the user has an iPod that was trying to connect to the Wifi and locking out the user due to incorrect password info…

%d bloggers like this: