Ping Servers in DMZ

Let’s say in a situation you need to check the connectivity
of few servers in DMZ from your management server.

Scenario: You have 20 Servers
running in your DMZ network. You need to check connectivity of these servers
everyday or once a week to make sure they are up and running. The manual
process would be:

1. From your working computer you log on to your Management Server from which
you can ping these servers. You use RDP to connect to Management server.

2. Ping each_server and get response from Management Box.

To avoid manual process you can use PSEXEC from to do so.

This is how you do it:

You know these servers are in DMZ and can be pinged only from Management
Server. You use a simple script to do so:

For one server you can use the following:

PSEXEC \\management_server ping server_in_dmz > c:\PingResponse\Response.txt

For more than one server you use the following:

1. A server.txt file to put all the servers in

2. A CMD or BAT file to ping all the servers and
store their result in %server_name%.txt file.


@echo off
Check Servers Ping Response in DMZ network.

set srvlist=servers.txt
rem ———————————–

echo.if not exist “%srvlist% (
echo Can’t find Server List file: %srvlist%

echo Processing all Servers……….
for /f “tokens=* delims=AU” %%m in (%srvlist%) do call:checknow



set srvname=%~1set srvname=%srvname: =%
psexec.exe \\management_server ping -w 1000 %srvname% >




Disaster recovery plan for Roaming Profiles (without clustering in effect).

Have you ever wondered? creating a disaster recovery plan for Roaming profiles without clustering. This is really interesting when someone wants to switch over Roaming profile in a network where one of DC is failing and other DCs are alive to serve the requests.


Let’s say you have two 100 client computers in your network and two domain controllers named: DC1 and DC2. All users have been configured with roaming profiles setup on DC1 and DC2. These users frequently log on to DC1 and switch over to DC2 in case of failure.

For some reasons, you want to create a disaster recovery plan for Roaming users – you want these users to switch over to DC2 and retreive their roaming profile from DC2 in case of DC1 failure.

Setup seems not so easy! but this is how you do it actually:

You need a startup script and deploy this script using Group Policy throughout the network.

This disaster recovery plan for romaing profiles can be designed by creating a Windows startup script. LOGONSERVER environment variable is common between these two DCs. You just need to set this in your script so that when script starts it should read the authentication server name and set in user’s property using LDIFDE tool.

You can see LOGONSERVER by typing SET command at command prompt. This tells by which DC this client was authenticated.

In the above scenario clients roaming profile are located at DC1.

1. Client starts

2. Netlogon finds a suitable domain controller for the client.

3. Sets the Environment variable: LOGONSERVER to the DC is about to authenticate client.

4. Startup script runs.

5. This script checks the path of Roaming profiles from the user’s property using LDIFDE tool.

6. Script pings the domain controller (let’s say client is configured to use romaing profiles on DC1 and DC2 is supposed to authenticate client in this regard.)

7. Script gets a “Request Timed Out” message from DC1.

8. Script assumes that this domain controller is not available on the network.

9. Then it takes the DC name from the LOGONSERVER environment variable and sets this LOGONSERVER in user’s property and in registry as well : \\DC2\profiles\%username%.

10. Netlogon passes control to Winlogon service.

11. Winlogon finally allows client to log on to computer.

12. Client logs on to computer. His profile path is checked and roaming profile is loaded from DC2 directly.

13. So in this case no failure is noticed.

LDIFDE – Export / Import data from Active Directory

LDIFDE is a robust utility. This utility enables you to import/export information from/to Active Directory. LDIFDE queries any available domain controller to retrieve/update AD information.


1. You can use LDIFDE to find any object. It may be a printer, a server, a computer, a user, a person. All these objects are identified with *ObjectClass=object_class_name (either printer or user or OU).

2. By default account is disabled when imported and also password is set to NULL.

3. To modify AD attribute you must put “-“ on a single line followed by a completely blank line on the next line. Please see the format below.

4. When a user is exported to LDF file, by default “changetype” is Add.

5. LDIFDE doesn’t support changing Group Membership. You can use CSVDE or ADDUSERS.exe or DStools for Windows 2003 Editions.

6. LDIFDE doesn’t support exporting Passwords.

7. By default “User must change password at next logon” attribute is selected.

8. LDIFDE doesn’t support importing Passwords. To change user’s password you need to convert from Plain Text to Base64 character. We can use a utility to convert from Plain Text to Base64.

9. Note that if no credentials are specified LDIFDE will use the currently logged on user’s credentials.

10. If you do an LDIFDE or CSVDE export, many of the attributes for user and group objects are owned by the system and cannot be re imported. Here’s a trick. Run the export with the –m switch. This enables SAM Logic, which is another way of saying that the export skips the attributes that are owned by the system. This gives you a template to use when building your import files or spreadsheets.

11. You can also export all user accounts from a forest (including data from all domains). This requires that you run the LDIFDE command against a Global Catalog Server with –t switch to specify the port No.

12. You must place a “-“ and then a blank line very next followed by the “-“ for modify and change operation to work properly. Otherwise LDIFDE will fail!

13. Using the setting “userAccountControl: 66048” enables the newly created account. By default, an account is created disabled. Note that user account can’t be enabled with blank password if you have a complex password policy defined on the domain. So you’re first step is to change the password and then enable the account.

                        userAccountControl: 514 for disable account

14. There are more export-specific options but not Import. Note that while exporting user accounts/OU/person you can use –o with –I but you can’t use both the switches while importing the file to AD. This is because both the switches are export-specific.

15. The default mode is Export Mode. You need to specify –I to turn Import Mode on.

16. If you want to carry the line to next line then the first must be a space and then start new line.

17. If you do not specify a server when you use LDIFDE to export objects that are in the domain-naming context, LDIFDE searches for a global catalog server. When LDIFDE searches for a global catalog server, it may not use the domain of the object name or the user account that you specify to determine what global catalog server to connect to. LDIFDE may connect to a global catalog server that is in the same site as the client, but that is a member of a different domain in the forest. This global catalog server may not have all the required Active Directory attributes for the objects that you want to export.  To work around this issue, use the -s server_name command-line option to specify a server when you use LDIFDE.

18. Ldifde sets password to blank unless you don’t have a complex password policy defined in your domain. Hence you can’t enable accounts with Blank Password.

19. Note that –o switch overrides –I switch if you plan to use both. Suppose you want to omit badPwdCount attribute from export and in the same command you specify –I switch to export this field. In this case attribute won’t be exported.

20. The contents of an object are on consecutive lines, starting with DN property. There must be an Empty Line if you want to perform an operation on another object.

21. Each property and its value must be on a separate line such as: givenname: dinesh. There should be a colon and a space.

22. DN property and its value must be placed at first line and any other property/value can be at any line.

23. Multiple values of a property should be on a separate line such as:

            Otherhomephoneno: 512 513

            Otherhomephoneno: 514 859

24. An empty value can be written by including only the property name with colon such as:    sn:

25. A line that starts with pound (#) sign is a comment line.

26. Base64 Encoding works as follow:

a. The value to be encoded is divided into three-byte sections

b. Each 24-bit Section is divided into four 6-bit value

               c. Each 6-bit value is mapped to one of the following 64 characters: uppercase alphabets A through Z, lowercase alphabets a through z, numbers 0 through 9, plus

               sign (+), or slash (/).This results in a string of basic alphabets, numbers, and possibly some plus signs and slashes. If the number of bytes in the original value is not a 

               multiple of three, the encoded value will have one or two equals signs (=) at the end, so the number of characters is always a multiple of four.

27. LDIFDE exports only attributes those have their values in AD. It doesn’t export attributes those don’t have values. For example: if description is not defined for a user then it won’t export description attribute.

28. When exporting ONLY ONE USER, make sure you don’t have dash (-) after the end of file.

29. When a new user account is created, it is made member of Domain Users group by default.

30. LDIFDE doesn’t accept blank values. Do not include blank values in LDF files. You will see errors.

31. LDIFDE doesn’t accept space in value while exporting. For example if samaccountname is Jacson Sam then you should enclose it within the quotas.


1. Command to export the user with a given name of SAM Account

ldifde -f exportuser.ldf -s computer_name -r (samaccountname=SAMLNAME)

2. Command to export Organizational Units:

Running this command exports all OUs except domain controllers into a file named ExportOU.ldf. 

ldifde -f exportOu.ldf -s Server1 -d “dc=Export,dc=com” -p subtree -r “(objectClass=organizationalUnit)” -l “cn,objectclass,ou”

3. Export the User Accounts from the Source Domain

ldifde -f Exportuser.ldf -s Server1 -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -l “cn,givenName,objectclass,samAccountName”

Running this command exports all users in the Export domain into a file named Exportuser.ldf. If you do not have all the required attributes, the import operation does not work. The attributes objectclass and samAccountName are required, but more can be added as needed.

4. Command to Import users from a LDF file:

ldifde -i -f Exportuser.ldf -s Server2

5. Exporting User Account attributes except attributes those can’t be imported: (Using –o switch)

This is another example filter that will export all User Account data except for the attributes that cannot be imported:

ldifde -f Exportuser.ldf -s <Server1> -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -o “badPasswordTime,badPwdCount,lastLogoff,lastLogon,logonCount, memberOf,objectGUID,objectSid,primaryGroupID,pwdLastSet,sAMAccountType”

Another Example: To export for any given SamAccountName:

ldifde -f Exportuser.ldf -s <Server1> -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -o “badPasswordTime,badPwdCount,lastLogoff,lastLogon,logonCount, memberOf,objectGUID,objectSid,primaryGroupID,pwdLastSet,sAMAccountType”

6. Exporting Objects from an Entire Forest (any given attribute will be exported with –i switch)

If you need to import everything from a forest you need to run LDIFDE command against Global Catalog server:

For example, to perform the export operation outlined against a GC, the LDIFDE command would be:

ldifde -f Exportuser.ldf -s Server1 -t 3268 -d “dc=Export,dc=com” -p subtree -r “(&(objectCategory=person)(objectClass=User)(givenname=*))” -l “cn,givenName,objectclass,sAMAccountName”

7. Simple Import of current domain: It will import only domain data NOT the Forest-Specific.

ldifde -i -f INPUT.LDF

8. Simple Export of current domain:   It will export only domain related data NOT the Forest-Specific.

ldifde -f OUTPUT.LDF

9. Export of a domain with supplied credentials:


           -d “cn=users,DC=DOMAINNAME,DC=Microsoft,DC=Com”

           -r “(objectClass=user)”

10. Exporting User or Person or Organizational Unit:

ldifde -v -s w2ks -d “dc=slowe,dc=com” -p subtree -r “(objectClass=clss_name)” -f usersonly.txt

You’ll notice a number of additional parameters here:

  • ·        -v turns on verbose mode so that I could see the results
  • ·        -d specifies the root of the search. While it was not required for this search, I included it to show you the format.
  • ·        -p narrows the search to the subtree in question. The other options for the –p parameter are base and onelevel.
  • ·        -r is used in the example with a parameter of “(objectClass=person)”. This parameter specifies the LDAP filter to use for LDIFDE. In my case, I wanted only people, so I chose an objectClass of “person.”

11. A Simple VBScript to change a user’s password: You can also modify strUser and strOU value:

strUser = InputBox(“Enter full name of user”)

strOU = InputBox(“Enter OU where user’s account resides”)

Set objUser = GetObject(“LDAP://CN=” & strUser & “,OU=” & strOU & “,DC=testdomain,DC=local”)

objUser.SetPassword “password”

MsgBox “Done!”

12. To change a user’s password using LDIFDE tool:

The following sample Ldif file (chPwd.ldif) changes a password to newPassword:

dn: CN=TestUser,DC=testdomain,DC=com
changetype: modify
replace: unicodePwd

ldifde -i -f chPwd.ldif -t 636 -s dcname -b username domain password