ADModify.NET is here!
Published Aug 04 2004 12:40 PM 75.9K Views

A quick intro to ADModify:

ADModify is a tool that was (and is still) developed and maintaned out of our Support Services (aka PSS) team, and was created to make it easier to modify / import / export objects in Active Directory in bulk. The tool has been available on the FTP site for download for a while, but with recent release of new version (ADModify.NET or v2.0) - we have decided to create a gotdotnet workspace for it too to make it easier for you to give us feedback on it :)

So - recently, Marc and I have released ADModify.NET.  ADModify.NET (v2.0) was written from the ground up using Visual C# .NET 2003.  When benchmarked against its predecessor, it made the same modifications in less than half the time.  Its new feature set allows administrators to bulk modify any AD attribute from any AD partition with almost limitless flexibility. 

Administrators will also find that they are no longer restricted by the attributes hard coded into the tool, as ADModify now contains the ability to modify any attribute just simply given its name and value.  ADModify is also no longer restricted to literal values; it is now possible to dynamically build values based off of current AD attributes.
 
Logging and Error handling has also improved dramatically.  All logging is now done using XML, making it much easier for administrators to manipulate and store the data and even take advantage of features such as Undo.  Keeping with the Windows 2003 initiative that everything that can be done in the GUI should be available via command line, a command line version of the tool that contains all of the same features is included as well.

It is worth noting that ADModify.NET requires the .NET Framework.  It also is worth noting that it will not run across a network drive.

Here is the download point:
http://www.codeplex.com/admodify

The rest of this blog covers the major new features that are available in ADModify.NET over the old version ADModify 1.6.

Terminal Server Attributes

It is now possible to modify Terminal Server attributes using ADModify.NET.  All TS attributes that are available in the Windows 2003 Active Directory Users and Computers users property page are available.  ADModify utilizes the TSUserExLib Library, so Windows 2003 or later is required to make Terminal Server setting modifications.  You do not have to be running a Windows 2003 domain; you will just simply need to run the program from a Windows 2003 Server for this specific functionality.

Mailbox Rights

Mailbox Rights are also now available for bulk modification.  There are 4 options when dealing with mailbox rights:

        -  Dump Mailbox Rights
        -  Import Mailbox Rights
        -  Bulk Add a User to Mailbox Rights
        -  Bulk Remove a User From Mailbox Rights

Since CDOEXM is utilized, Exchange 2000 or later ESM must be installed on the machine that ADModify.NET is run on to be supported.

Dump Mailbox Rights

This option will export all of the ACE's in a users mailbox rights to an XML file, separated by inherited and non-inherited rights.  This file can be used as a way for administrators to track mailbox rights and can also be used to import.  Undo is not supported when using this option, as it is a read only operation.

Import Mailbox Rights

As long as a valid export of mailbox rights has been completed, the Import Mailbox Rights option can be used to import them.  All that is required is a valid mbxrights.xml file.  Undo is also not supported here.
 
Bulk Add a User to Mailbox Rights

With this option it is possible to add a user with specific rights to multiple mailboxes at the same time.  For example, you could grant the user DOM\user1 Full Mailbox Access to a specific subset of users with relative ease.  Undo for this operation is supported.
 
Bulk Remove a User From Mailbox Rights

Same as the Bulk Add option except this option will remove the specified user from mailbox rights.  Undo for this operation is supported.

Name that attribute!

Possibly the most robust new feature of ADModify is the flexibility to simply name the attribute you wish to modify.  Any attribute that contains a string, Boolean (true/false), or integer value can be modified in this fashion (attributes that contain data types such as SIDs and Long Integer are not supported). 

In here, simply fill in the attribute name and value.  For multivalued operations, be sure to choose append or remove.  The reason is simply this:  if you modify a multivalued attribute and do not choose the multivalued option, the attribute will be overwritten with the new value, not appended.

Using Variables

Administrators are no longer restricted to using literal values when bulk modifying users.  ADModify now supports the use of variables.  What are variables?  They simply allow you build a value for an attribute based off of one or more current attributes.  The syntax is simple.  Simply enclose the value in single ticks (') to treat it as a variable.  If you wish to build an attribute using both variables and literal values, just remember that variables need to be separated from literal values using the percent sign (%).  You can also take the first x number of characters from an attribute and use that as well.

Example:
Syntax for using the description attribute as your value:  'description'
Syntax for using two attributes, givenName and sn (separated by a space):  %'givenName'% %'sn'%
Syntax for using multiple attributes and literal values:  h:\homefolders\%'sAMAccountName'%\%'givenName'%\
Syntax for taking the first character of an attribute:   %1'givenName'%.%'sn'%@microsoft.com

If the need should arise to actually use the % or ' characters in an attribute value, simply use a preceding forward slash as an escape character. You can mix variables with literal values, even the % and ' characters as long as the correct syntax is used.

Example:
To assign the value "This is a percent sign: %", use this:  This is a percent sign: /%
To assign the value "My username is 'username' " (where username is the sAMAccountName), use this:  My username is /'%'sAMAccountName'%/'

Undo Feature

Administrators need no longer fear making massive bulk updates to AD Users.  With the exception of the "Remove Exchange Attributes" and "Import Mailbox Rights" options, every modification is undo-able.  All modifications are written to a log file named after the current date and time, in MMDDYYYYHHMMSS.xml format.  All modifications will not only log the new value, but the user’s previous value.  As long as the log file is in tact, ADModify.NET can parse it and undo the changes that were previously done.  In addition to the changes that were made being logged to the XML file, there is also an undo.log file.  This file contains all users processed by undo and logs skipped users, the reason for the user being skipped, and a summary of changes.

Command Line syntax:  admodcmd -undo filename.xml

admodcmd - ADModify.NET in Command Line

admodcmd.exe is a fully functional command line version of ADModify.NET.  Syntax can be obtained using admodcmd -?.  However, below you will find some examples for common administrative tasks.

1.  Adding a secondary SMTP address of firstinitial.lastname@company.com
       admodcmd -dn OU=MyOU,DC=domain,DC=com -addsmtp %1'givenName'%.%'sn'%@company.com

2.  Name the attribute you wish to modify
       Modify the description field to contain the value "My legacyExchangeDN is (legacyExchangeDN)", where (legacyExchangeDN) is the users legacyExchangeDN:
       admodcmd -dn OU=MyOU,DC=domain,DC=com -custom description "My legacyExchangeDN is %'legacyExchangeDN'%"

3.  Modify the display name to read last name, first name
       admodcmd -dn OU=MyOU,DC=domain,DC=com -custom displayName "%'sn'%, %'givenName'%"

4.  Modify the users Relative Distinguished Name (CN) from firstname lastname to lastname, firstname
       admodcmd -dn OU=MyOU,DC=domain,DC=com -modrdn "%'sn'%, %'givenName'%"

These are just a few of the examples.  For more sample usage on admodcmd, consult the ADModify.NET help.

- Dan Winter

15 Comments
Not applicable
I like the program, it can be very useful, for the moment I find that it can be more useful if you can see the actual value of the attribute.

Sorry for my english and congratulations for you job.
Not applicable
Exchange-faq.dk - Din portal til Microsoft Exchange Server information
Not applicable
Since we're on the topic of AD Attributes, I need to ask one question. For those of us who have worked with Exchange since the early days, the legacyExchangeDN is a self explanitory attribute. But as a consultant, I find myself telling new Exchange customers to ignore the DN syntax since the AG's are not really OUs and there really is not and AD container called "recipients". This attribute is named "legacy"ExchangeDN, yet I see Exchange 2003 place continued and rightful importance on it's value. I see it's use in the XML message tracking schema...Or how about having to add the x500 format to migrated users...MAPI clients use it...Can some one explain why this attribute is still considered(named) legacy and when will we see changes to it's name?
Not applicable
I have used ADMODIFY extensively and it has to be included as Support tool like EXMERGE .
Not applicable
Trouthunter,
LegacyExchangeDN is called "legacy" because it is a direct mapping to a lower major version of Exchange. We need it to be there and use it heavily to ensure backwards compatibility. I would imagine that it will be phased out when Exchange 5.5 is no longer supported - but that remains to be seen...
Not applicable
I'm just suprised to see that there isnt an attribute called msExchx500DN or a proxyaddresses value for the x500 address for use in current e2k and e2k3 functionality, and either have the RUS sync the value to the legacyexchangeDN property, build code to support both values much like the properties msExchpreviousSID, msExchMasteracctsid, etc.

Plus, using your logic...Exchange 2006 will need to use it to support its 'legacy' use of that attribute deployed in Exchange 2000 and 2003!
Not applicable
Trouthunter,
I can’t speak to why the attribute was specifically called legacyExchangeDN and not msExchX500DN. However I can reason it was not listed as a X500 address in the proxyAddresses list because we would need to map a single X500 address back to Exchange 5.5, and the proxyAddresses attribute is a Multi-valued string. It would be easy to have multiple X500 addresses defined within proxyAddresses, and then how do you decide which one maps back to Exchange 5.5? Think of it how you can only have one email address that replicates back to 5.5 Site Addressing specified in a Recipient Policy that is scoped to an Exchange 5.5 site. The restriction is present because of the design of the legacy product. By this you could certainly reason that since Exchange 6.x is dependant on that attribute, later versions of Exchange may very well still have the legacyExchangeDN attribute present and used—but at this point it truly is speculation.
Not applicable
Can someone tell me what attributes are cleared using the "Kill Mail Attributes" checkbox?
Not applicable
Mike, it is the same as mentioned here:


ftp://ftp.microsoft.com/pss/Tools/Exchange%20Support%20Tools/killmailuser/readme.txt



In other words - list of attributes removed:


"deliverAndRedirect",

"homeMDB",

"homeMTA",

"mail",

"legacyExchangeDN",

"proxyAddresses",

"showInAddressBook",

"msExchADCGlobalNames",

"mailNickname",

"replicatedObjectVersion",

"replicationSignature",

"targetAddress",

"msExchMailboxSecurityDescriptor",

"dLMemDefault",

"textEncodedORAddress",

"mAPIRecipient",

"mDBUseDefaults",

"msExchALObjectVersion",

"msExchHideFromAddressLists",

"msExchHomeservername",

"msExchMailboxGuid",

"msExchPoliciesIncluded",

"msExchPreviousAccountSid",

"msExchUnmergedAttsPt",

"msExchUserAccountControl",

"msExchMasterAccountSid"

Not applicable
When setting the "Terminal Services Home Folder' I do not have the C: drive as an option but all other drives show up. ADModify is perfect for what I need to do and works if I assign a different drive but I need C:. Any ideas?
Not applicable
The option you are using is for mapping a drive to the profile location. Since C: is always used by the OS and is generally not a mapped drive, it was left out of the available drive list. If you want to map a profile to the C: drive locally, use the "Local Path" option instead.

However, if you need this changed just reply and let us know and it will be taken care of.
Not applicable
I dont really need it changed. I tricked it a bit by setting it to D: then in the xml file setting D: to C: and doing an undo, but it would be nice to have that option. We are using this for Citrix users where C: is a valid option for the users but it is not necessary. If you really want to change this it would be most appreciated.
Not applicable
Done! The change will show up in the next release. Periodically check

http://www.gotdotnet.com/Community/Workspaces/viewUploads.aspx?id=f5cbbfa9-e46b-4a7a-8ed8-3e44523f32...

as this is where we post the latest version of the tool.
Not applicable
Marc...Thanks alot for your help. I look forward to the next release. Again, thanks!!
Not applicable
Version history
Last update:
‎Jul 01 2019 02:59 PM
Updated by: