Unlock AD Data Management with CSVDE and LDIFDE

Active Directory (AD) is a major IT resource for many organizations. It makes sense to manage AD from the command line, especially when there is bulk data or scripting involved. PowerShell is a great tool for managing AD in this way, but what if you don’t, won’t, or can’t use PowerShell?

Two handy command-line utilities that don’t get the fanfare that PowerShell does, are called csvde and ldifde. These tools allow you to import, exort, or modify AD data from the command line.

These two tools ease the burden of migrating data between AD domains or importing data from non-AD LDAP directory services. They do this by allowing you to use standard plain text files (CSV and LDIF) to move AD data.

In this article, you will learn the power that each of these tools has!

What are CSVDE and LDIFDE?

Comma Separated Value Directory Exchange (CSVDE) and LDAP Data Interchange Format Data Exchange (LDIFDE) are a pair of tools designed to manage the import and export of Active Directory (AD) data to and from text files. CSVDE imports and exports from Comma Separated Values (CSV) files. Ldifde, on the other hand, imports and exports from LDAP Data Interchange Format (LDIF) files.

Common Parameters

In this article, you’ll learn many different actions you can take with these tools. Each one of these actions will be performed via one or more different parameters.I

One thing you will immediately notice if you work with both csvde and ldifde is that they have similar parameters. Each tool performs similar purposes but does it in a different way.

Below you will find a table that outlines each parameter and their purpose.

Distinguished Name Translation

With ldifde, you have the ability to export data from one domain and import into another. But what about domain-specific references like an AD object’s distinguished name (DN)? Luckily, these tools provide a way to handle for such circumstances through a concept called DN translation.

DN translation allows you to “inject” a particular domain DN during import and export operations using the  -c parameter. When the  -c parameter is used in the form -c FromDN ToDN , any occurrences of FromDN are swapped to ToDN.

In the following example, the distinguished name DC=lab,DC=local is replaced by DC=corp,DC=local.

> csvde -f export.csv -c DC=lab,DC=local DC=corp,DC=local

Macro Expansion

LDIFDE also supports the concept of macro expansion. Macro expansion is the ability to use a shortened name or macro to refer to some of the well-known naming contexts in LDAP. Ldifde supports the following macros:

Perhaps you have an employee, Fiona Cortez, that you’d like to export from the corp.local domain and import into the lab.local domain. Fiona’s user object is exported to an LDIF file named fiona.ldf using the following command:

> ldifde -f fiona.ldif -r "samAccountName=Fiona.Cortez"
Exporting directory to file fiona.ldif
Searching for entries...
Writing out entries.
1 entries exported

If you open up Fiona’s AD object record in the fiona.ldf file, it would look something like this:

dn: CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local
changetype: add
accountExpires: 9223372036854775807
cn: Cortez Fiona
description: Systems Analyst
distinguishedName:
 CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local
dSCorePropagationData: 16010101000000.0Z
givenName: Fiona
instanceType: 4
mail: [email protected]
name: Cortez Fiona
objectCategory:
 CN=Person,CN=Schema,CN=Configuration,DC=corp,DC=local
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
sAMAccountName: Fiona.Cortez
sn: Cortez
userAccountControl: 546

An attempt to import this record into the lab.local domain using ldifde -i results in an error as shown below:

> ldifde -i -f fiona.ldf
Importing directory from file "fiona.ldf"
Loading entries.
Add error on entry starting on line 1: Referral
The server side error is: 0x202b A referral was returned from the server.
The extended server error is:
0000202B: RefErr: DSID-031007F9, data 0, 1 access points
ref 1: 'corp.local'
0 entries modified successfully.
An error has occurred in the program

To get Fiona’s user object to import into the lab.local domain, change each occurrence of corp.local to lab.local for each distinguished names in the LDIF file. You could do this manually, but macro expansion can do this for you using the #defaultNamingContext macro. The #defaultNamingContext macro represents the default naming context of the AD domain.

The default naming context for an AD domain is the part of an object’s DN. The DN is  made up of domain components or DCs (not to be confused with domain controllers). For example, in the distinguished name CN=Cortez Fiona,OU=All User Accounts,DC=corp,DC=local, the domain components are DC=corp,DC=local. The default naming context for the corp.local domain is DC=corp,DC=local.

The following command imports Fiona’s record successfully. In this case,  #defaultNamingContext is cn=lab,cn=local. All occurrences of cn=corp,cn=local in distinguished names are changed to cn=lab,cn=local.

> ldifde -i -f fiona.ldf -c "cn=corp,dc=local" "#defaultNamingContext"

Using macro expansion with the -c parameter is only supported by ldifde and LDIF files. The same approach cannot be used with csvde and CSV files.

LDIF Parameters

Even though both tools have similar parameters, ldifde diverges a bit by including a few parameters that csvde does not have. These parameters perform actions specific only to the ldifde tool.

Working with LDIFDE and CSVDE

In the remainder of this article, you’ll learn hands-on how to use these useful tools.

Prerequisites

If you intend to follow along, be sure you have the following prerequisites met ahead of time:

1. Windows 7 or higher OS
2. Microsoft Excel or a similar spreadsheet program installed on your computer will help when viewing CSV files generated by csvde.
3. Remote Server Administration Tools (RSAT)

Exporting AD Objects From the Current Domain

Perhaps you need to export information from AD. You can easily do this using the -f parameter which allows you to specify a file.

The command below exports everything in the current AD domain to a file specified by the -f parameter.

> csvde -f export.csv
> ldifde -f export.ldf

This could take a long time in a production environment and impact performance of AD.

A typical CSV export file for a whole domain would look like the below CSV when viewed in Excel.

Importing AD Objects Into the Current Domain

If you already have a CSV file containing AD objects, you can use the -f parameter on either tool. Perhaps you’re now importing AD information from the import.csv file exported earlier. To do this, use the -i parameter.

For an example, using the -i and -f parameters, you can impot everything that the import.csv file has in built above.

> csvde -i -f import.csv

> ldifde -i -f import.ldf

Understanding How CSVDE Translates Data

Csvde changes some of the information returned by AD when you export it. It does this so that it can be stored in a plain text format like CSV. This behavior might catch you by surprise if you are modifying the data in Microsoft Excel, or the system you are importing it into is not Active Directory.

Let’s have a look at a CSV export file pc.csv from the lab.local domain. This file was generated by csvde for the user Paul Cox. Using the -r parameter to specify an LDAP filter picks out Paul by his samAccountName.

> csvde -r "samAccountName=Paul.Cox" -f pc.csv
Exporting directory to file pc.csv
Searching for entries...
Writing out entries
.
Export Completed. Post-processing in progress...
1 entries exported

The structure of pc.csv  can be examined by opening it in Excel or another spreadsheet program. It will look something like this:

Looking at the column headed memberOf shows how csvde handles multi valued AD properties. You can see below that csvde separates values with a semicolon (“;”). The semicolon is highlighted in the image below. It’s quite hard to spot amongst all the commas.

Looking at the objectGUID column in pc.csv shows how csvde handles AD properties that are not directly representable as text or numbers – the program exports a value prefixed by “X” and wrapped in single quotes.

Presenting the value in this way means that csvde has taken the value of objectGUID and changed it to make it able storable in a plain-text format like CSV. When the file is imported by csvde the objectGUID value will be converted before being sent to AD. There doesn’t appear to be any documentation about how these values are changed or changed back.

Below you’ll find a table of AD properties that are encoded and which objects in AD have that particular property.

Exporting User Accounts

Maybe you need to export only user accounts. To make things more interesting, let’s also assume you’re not currently logged into a computer with access to query AD. You need to specify alternate credentials.

In the example below, the -m parameter means that information that the program considers sensitive, such as objectGUID and objectSid. These attributes are not exported. The -r parameter sets the LDAP filter to use.

> csvde -m -f export.csv -a [email protected] P@$$w0rdH3r3 -r "(objectCategory=user)"

> ldifde -m -f export.ldf -a [email protected] P@$$w0rdH3r3 -r "(objectCategory=user)"

A typical CSV export file containing user objects would look like this in Excel:

Exporting all Objects in an Organizational Unit (OU)

If you don’t want to export all objects in AD, you can also only export those in a specific OU.

The following command exports all objects from an OU, including the OU object itself and any sub-OUs. A default LDAP filter of "objectClass=*" (all objects) is used if we don’t supply one using -r. The -d parameter sets the starting point for the search in the directory tree. In this case, it is set to the OU that in which we are interested, as shown below.

> csvde -f ouexport.csv -d "OU=All User Accounts,DC=lab,DC=local"

> ldifde -f ouexport.ldf -d "OU=All User Accounts,DC=lab,DC=local"

When you use csvde or ldifde to export AD object to a file, the objects in the file are listed in a particular order. This is the order that will be used when when the data is imported into another domain or LDAP service.

For example, the OUs are created before the user objects within the OUs. Additionally, linked attributes like manager are added after all of the users have been created. Below is an example LDIF file (snipped for brevity), showing the order of object creation and modification:

dn: OU=All User Accounts,DC=lab,DC=local
changetype: add
distinguishedName: OU=All User Accounts,DC=lab,DC=local
---SNIP---

dn: CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local
changetype: add
distinguishedName:
CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local
---SNIP---

dn: OU=Professional Services,OU=All User Accounts,DC=lab,DC=local
changetype: add
distinguishedName:
 OU=Professional Services,OU=All User Accounts,DC=lab,DC=local
---SNIP---

dn: CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=lab,DC=local
changetype: add
distinguishedName:
 CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=l
 ab,DC=local
---SNIP---

dn: CN=Davis Bethany,OU=Professional Services,OU=All User Accounts,DC=lab,DC=local
changetype: modify
add: manager
manager:
CN=manager: CN=Smith Brian,OU=All User Accounts,DC=lab,DC=local
-

Exporting Specific Attributes of User Accounts

There will be some situations where you don’t need to export all of the information about a user using csvde or ldifde. Examples include the data for creation of physical phonebooks, or the export of user information for import into another, non-Active Directory system. –

This example uses the -l parameter to allow the export of specific attributes of objects. The export file contains the Given Name, Surname, Telephone Number, and Email address of each user. These attributes attributes are specified via the -l parameter .

> csvde -f export.csv -r "objectCategory=user" -l givenName,sn,telephoneNumber,mail

> ldifde -f export.ldf -r "objectCategory=user" -l givenName,sn,telephoneNumber,mail

Modifying Active Directory Objects

While csvde and ldifde are both designed for bulk data import and export, ldifde can make changes to AD objects. As an example, Microsoft uses LDIF files to extend the AD schema. The LDIF file format is designed to support these actions.

There is no equivalent in CSV files used by csvde to the LDIF changetype. Csvde can only import or export AD objects.

Bear in mind that some of the attributes you export from AD cannot be written back to. These attributes are system generated, or are restricted to system access only. Examples include:

badPwdCount
badPasswordTime
lastLogoff
lastLogon
pwdLastSet
primaryGroupID
objectGUID
objectSid
logonCount
sAMAccountType

Using changetype

The changetype lin is a key piece of information in an LDIF record that allows it to be used for different kinds of actions. The changetype line in an LDIF file sets the action that is going to happen to an object in AD specified by the DN line above the changetype, as shown in the example below.

dn: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local
changetype: add

There a different kinds of changetype and these are summarized in the table below:

Using the Add changetype

The Add changetype creates a new AD object. The values for attributes are supplied one per line for single valued attributes and on multiple lines for multi valued attributes. An add record looks like the example below (snipped for brevity).

Note that the second line (changetype: add) identifies this as an add record.

dn: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local
changetype: add
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: Cox Paul
sn: Cox
description: IT Manager
givenName: Paul
distinguishedName: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local
---SNIP---

Using the Delete changetype

The delete changetype removes an object from AD and is simple in structure. The DN  is the only mandatory attribute required in the LDIF file, specifying the DN of the AD object to be deleted.  This is followed by a changetype line of changetype: delete, as shown below.

dn: OU=Legacy OU,DC=lab,DC=local
changetype: delete

You can delete many kinds of objects using ldifde. You could easily destroy your AD installation using ldifde the wrong way. Be warned!

Using the Modify changetype

The modify changetype has add, delete, and replace operations that are applied to attributes of the selected AD object. Below is an example LDIF file showing how this can be used in practice. The example replaces Angelique’s telephone number, adds her office location, and deletes her fax number.

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: modify
replace: telephonenumber
telephonenumber: +44 1234 567890
-
add: physicaldeliveryofficename
physicaldeliveryofficename: Corner Office
-
# No one uses faxes, do they?
delete: facsimiletelephonenumber
-

Using the ModDN/ModRDN changetype

The moddn or modrdn changetype is used to rename or move an AD object in the directory tree.

Use the newsuperior value to set where the object will be moved to. The mandatory newrdn value sets the name of the object. The deleteoldrdn value determines if the old rdn is kept or replaced by the newrdn value. Omit the newsuperior value if the object should be renamed in place. Child objects of the object being moved are also moved.

An example LDIF file to move the Professional Services OU from under the Services OU is shown below.

dn: OU=Professional Services,OU=Services,DC=lab,DC=local
changetype: modrdn
newrdn: OU=Professional Services
deleteoldrdn: 1
newsuperior: DC=lab,DC=local

Updating an Attribute

Let’s explore how to update the value of an existing AD attribute using ldifde.-

In this example the description attribute for a user is updated. First, the user’s description attribute is exported to an LDIF file to create a template to modify, as below. The -l parameter specifies the attributes to be present in the LDIF file. The -r parameter sets an LDAP filter used to determine the objects that ldifde returns.

> ldifde -r "samAccountName=Angelique.Cortez" -f ac.ldf -l description
Exporting directory to file ac.ldf
Searching for entries...
Writing out entries.
1 entries exported
The command has completed successfully

The resulting file ac.ldf, looks like below:

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: add
description: Compliance Guardian

To make this a modify record, the changetype is changed to modify and a replace line specifying the attribute to be modified is added. The description line is changed to the new value. Finally, a new line containing “-” on its own is added to mark the end of the change. The file looks like the example below when it is saved:

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: modify
replace: description
description: General Manager
-

Running ldifde with the -i parameter imports the changes into AD, as seen below.

> ldifde -i -f ac.ldf
Importing directory from file "ac.ldf"
Loading entries..
1 entry modified successfully.
The command has completed successfully

Repeating the export step above and viewing ac.ldf reveals that the change has taken place.

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: add
description: General Manager

Modifying Members of an AD Group

Let’s explore how to modify the membership of an AD group using ldifde.-

In this example the membership of the group Professional Service Department is changed.

For example, export the group to an LDIF file called psd.ldf using the -m and -n switches. These switches remove security sensitive and binary attributes from the data that is returned. The command to achieve this is shown below.

> ldifde -r "cn=Professional Services Department" -f psd.ldf -m -n

The file psd.ldf is shown below (snipped for brevity).

dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local
changetype: add
cn: Professional Services Department
distinguishedName: 
 CN=Professional Services Department,OU=All Groups,DC=carisbrookelabs,D
---SNIP---

dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local
changetype: modify
add: member
member: CN=Cox Paul,OU=All User Accounts,DC=lab,DC=local
-
dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local
changetype: modify
add: member
member:
 CN=Diaz Kristin,OU=Professional Services,OU=All User Accounts,DC=lab
 ,DC=local
-

The order of entries in the psd.ldf means that the group is created first and then members are added. Note that the member attribute contains a DN, rather than a samAccountName, SID or commonname. That’s how the attribute is stored in AD.

For this example, let’s assume that the user Angelique Cortez needs to be added to the Professional Services group. Her distinguished name is CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local. The export file psd.ldf shows the LDIF format needed to add a user to a group. This consists of a changetype of modify, an add line, and a member line.

Don’t forget to add the “-” on its own line to finish the modify record.

Following the example of the export file, the new LDIF file, which has been saved as group.ldf,  looks like this:

dn: CN=Professional Services Department,OU=All Groups,DC=lab,DC=local
changetype: modify
add: member
member: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
-

The LDIF file is imported using the -i parameter, as shown below.

> ldifde -i -f group.ldf

Assuming there are no errors, Angelique will have been successfully added to the group.

Resetting a User Password

Resetting a password using an LDIF file requires changing the user’s unicodePwd attribute. The new password must be wrapped in double quotes (NewPassword must be supplied as “NewPassword”) and base64 encoded. The new password must also conform to any password policies applicable to the user, such as length or complexity. Failure to meet these requirements will cause the password change to fail.

In the example below, the user’s password is changed and the userAccountControl attribute’s value is replaced with the value 512. This behavior enables the account.

LDIF files involving password changes must be imported over a secure connection. Use port 636 using the -t parameter, or Simple Authentication and Security Layer (SASL) using -h. Attempts to modify passwords over insecure connections will fail.

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: modify
replace: unicodePwd
unicodePwd::IgBGAGwAeQBpAG4AZwBJAHMATQB5AFQAaABpAG4AZwAxACIA
-
replace: userAccountControl
userAccountControl: 512
-

Adding a Photo to a User Account

The ldifde tool allows you set the [jpegphoto](https://docs.microsoft.com/en-us/windows/win32/adschema/a-jpegphoto) attribute for a user by specifying a file name in the LDIF file. In the example below, the file specified is loaded into the jpegphoto attribute. Note that the file path follows the file URI scheme, and that forward slashes are used.

dn: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
changetype: modify
replace: jpegphoto
jpegphoto: < file:///photos/angeliquephoto.jpg
-

The content of the file is not checked in any way for invalid or malicious content before it is loaded. Be warned!

Troubleshooting

Although the csvde and ldifde tools can save you tons of time, things don’t always go as expected. In this section, you’ll find many pointers to help you deal with various issues you may come across.

Creating Logs for CSVDE and LDIFDE

Use the -j parameter to create logs of the import or export. This parameter should point to a directory where the log files will be created. The logs themselves are plain text files, called csv.err and csv.log for csvde and ldif.err and ldif.log for ldifde. The *.log files contain logs of all activity, whilst the *.err files only contain any errors.

For example, a failed csvde import generates a csv.log file like this:

Connecting to "lab.local"
Logging in as "[email protected]" using simple bind
Importing directory from file "dc.csv"
Loading entries2: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
Attribute 0) description: Team Leader
Attribute 1) distinguishedName: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
Attribute 2) objectClass: userEntry already exists, entry skipped.
0 entries modified successfully.
The command has completed successfully

The .err file for the same error looks like this:

Attribute 0) description: Team Leader
Attribute 1) distinguishedName: CN=Cortez Angelique,OU=All User Accounts,DC=lab,DC=local
Attribute 2) objectClass: user
2: Entry already exists, entry skipped.

If your LDIF file doesn’t contain expected attributes when using the -l or -o switches, check the spelling on any attribute names that you wish to include or omit. Additionally, always check the spelling of server names, file names, etc. Any mistakes in these will also cause import or export failures.

“There is a syntax error in the input file”

This generic error identifies where in the LDIF or CSV file the import is failing:

Failed on line 3. The last token starts with 'n'.*

“A device attached to the system is not functioning”

This error is seen when using ldifde to change a user’s password. There are two possible causes.

Add error on entry starting on line 1: Unwilling To Perform
The server side error is: 0x1f A device attached to the system is not functioning.
The extended server error is:
0000001F: SvcErr: DSID-031A1254, problem 5003 (WILL_NOT_PERFORM), data 0

Cause 1 – Password incorrectly formatted

Ensure that you are replacing the unicodePwd attribute with a base64 value. The password must be a Unicode string wrapped in double quotes before base64 encoding. There are a number of approached you could use to base64 encode the password, including online services and command line tools. Here’s how you could base64 encode a password using PowerShell.

PS51> [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes('"PassWordInQuotes1"'))
IgBQAGEAcwBzAFcAbwByAGQASQBuAFEAdQBvAHQAZQBzADEAIgA=

Cause 2 – Trying to set a password over an insecure connection

Another cause could be when you try to set a user’s password, but don’t use a secure connection.-

Use the -t 636 (use port 636) or-h (use SASL)  parameters to secure your connection to AD. If not, password updates will fail.

“Errors on Line 2”

You will occasionally come across error message returned by csvde that start with “errors on line 2.”. This usually means that the file format is incorrect.

This error could mean that incorrect attribute names have been used for column headings in a CSV file for example. Line 2 of a CSV file is the first data line after the headers. This error means that the import process has failed at the very start.

To illustrate this error, have a look at the following snippet from a CSV file. The columns for the user’s first and last names are headed firstName and lastName (instead of givenName and sn). The import will fail with an error on line 2 of No Such Attribute.

“Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM)”

Several AD attributes cannot be set via script. They are managed by AD itself – trying to modify one of these triggers this error.

Add error on line 2: Unwilling To Perform
The server side error is "Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM)."

Use the-m parameter when exporting to exclude the restricted attributes from the output file. Also, attributes that are backlinks to other attributes (such as memberOf, manager) cannot be set directly. Below is a (probably incomplete) list of attributes you can’t set using csvde and ldifde:

objectGUID
objectSid
whenCreated
whenChanged
uSNCreated
uSNChanged
badpasswordTime
lastLogoff
lastLogon
pwdLastSet
lastLogonTimestamp
dSCorePropagationData
badPwdCount
logonCount
lockoutTime
instanceType
accountExpires
objectCategory
sAMAccountType
memberOf
manager
primaryGroupID

“The specified account already exists”

CSVDE doesn’t have the ability to update or recreate existing AD objects. If you try, you’ll get the following error message.

Add error on line 2: Already Exists
The server side error is "The specified account already exists."

“Illegal modify operation. Some aspect of the modification is not permitted”

Constraints within AD can prevent actions from taking place, for example trying to delete an OU when its isCriticalSystemObject attribute is set to True. Unfortunately, the error message is not specific about which change is not permitted.

The server side error is: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted.
The extended server error is:
00002077: SvcErr: DSID-031B0F19, problem 5003 (WILL_NOT_PERFORM), data 0

“Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain”

The error message tells the story here. Ensure that any password you are trying to apply meets the requirements of the AD domain. See the Password Policy documentation on Microsoft Docs for more details on how these requirements are defined.

Add error on entry starting on line 1: Unwilling To Perform
The server side error is: 0x52d Unable to update the password. The value provided for the new password does not meet the length, complexity, or history requirements of the domain.
The extended server error is:
0000052D: SvcErr: DSID-031A1254, problem 5003 (WILL_NOT_PERFORM), data 0

“The parameter is incorrect”

The extended error  part of the message gives a clue. In this case deleteoldrdn value needs to be set to 1 in the LDIF file.

Add error on entry starting on line 1: Unwilling To Perform
The server side error is: 0x57 The parameter is incorrect.
The extended server error is:
00000057: LdapErr: DSID-0C090E43, comment: Old RDN must be deleted, data 0, v3839

“The operation could not be performed because the object’s parent is either uninstantiated or deleted”

This error means that the specified new location for a move operation does not exist. The newsuperior value in the LDIF file is likely wrong.

Add error on entry starting on line 1: Other
The server side error is: 0x2089 The operation could not be performed because the object's parent is either uninstantiated or deleted.
The extended server error is:
00002089: UpdErr: DSID-031B0DCE, problem 5012 (DIR_ERROR), data 2

“A referral was returned from the server”

The objects you are trying to import have DNs that don’t match the domain you are trying to import into. Use the macro capability to fix this, or manually change the distinguished names to the correct value before importing.

Add error on entry starting on line 1: Referral
The server side error is: 0x202b A referral was returned from the server.
The extended server error is:
0000202B: RefErr: DSID-03100835, data 0, 1 access points

“Directory object not found”

This error occurs when you include a DN that does not exist in your import file. Has the object in question been deleted? Check for typos in the distinguished name.

Add error on entry starting on line 1: No Such Object
The server side error is: 0x208d Directory object not found.
The extended server error is:
0000208D: NameErr: DSID-03100241, problem 2001 (NO_OBJECT), data 0, best match of:
'DC=lab,DC=local'

“A required attribute is missing”

AD objects require certain mandatory attributes to be present before you can create them. This error reports that one of the attributes is missing. Unhelpfully, it doesn’t say which one. To find out which attributes are mandatory for a particular object class, have a look at the AD schema documentation.

Add error on line 2: Constraint Violation
The server side error is "A required attribute is missing."

“Unable to read the import file”

This error usually means that the file is not present in the specified location. Check the file path and spelling.

Unable to read the import file <filename>

“Error opening the output file”

This error could mean that the file is in use by another process. Make sure that the export file is not open in another program.

Error opening output file.

“The connection cannot be established. The error code is 8224”

Check that the server, domain, or forest name being used is correct and that network connectivity exists to the domain controller.

“SSPI “bind with supplied creds” returned ‘Invalid Credentials’ or Simple bind returned ‘Invalid Credentials’”

This error means that the user name or password you are using to authenticate to AD is incorrect.

“Invalid Parameter: No Active Directory Domain Controller Available”

This error means that computer you are running csvde or ldifde on is cannot detect an AD domain. Specify a server using -s (you’ll probably need to specify credentials too, using the -a or -b parameters).

Further Reading

• The LDAP Data Interchange Format (LDIF) – Technical Specification
• Learning Active Directory and LDAP Filters in PowerShell