ADModify.NET is here!
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 WinterA brief history of time - Exchange Server way
Ever wondered how Exchange Server evolved over the years? And how come Exchange Server 2007 shows "8.0" as its version number? Here is a brief history of time... it might add a bit to the known history! First Exchange proof of concept was in the early 90's. Development team usage only. Mercury - we couldn't get Exchange to scale past 25 users. We were bleeding internally with Xenix mail, so we figured that we'd keep Exchange alive but just use it as a MIR (Microsoft Internal Release). A perf and scale team was put in-place to see what we could do about the abysmal performance. Touchdown - the perf and scale team figured out the important issues, and Exchange once again had the potential to become an external release, marketed and sold by Microsoft. Indeed, after several test releases, we shipped in early '96 as Exchange 4.0 4.1 - Exchange 4.0 spent a long time in development, but it was a little rough around the edges. We immediately started work on a 4.1. After having implemented X400 as the primary messaging protocol and an X500-like directory structure, we quickly realized that this Internet 'thing' was really going to take off. It started to become obvious that we needed more than a .1 release. The 4.1 moniker was dropped and we were now working toward 4.5. After implementing several ground-breaking protocols such as SMTP and LDAP v2, this was certainly not a dot release. We shipped as Exchange 5.0 in early '97. Exchange 5.0 brought another important technical addition - the introduction of a Web-based e-mail client called Exchange Web Access (EWA). EWA was subsequently renamed Outlook Web Access (OWA). EWA was revolutionary for its time. It allowed employees or other individuals with mail stored in an Exchange 5.0 or later server to use a web browser to access their e-mail from anywhere at any time. In other words, the Exchange server provided the necessary information and interface through the web browser, no special e-mail client application was required on the user's machine. While on the subject of Exchange 5.0: If you still have an Exchange 5.0 CD around, there is an Easter egg on the CD in the form of a file called EXGL32.DLL. Rename that file to .AVI and view it... it is essentially credits for all the people that worked on Exchange 5.0 and while at it, we made some fun about the versioning in it too. Just so you get an idea: The Exchange 4.1 Team! Oh... wait... The Exchange 4.5 Team! Uh... let's try this again... The Exchange 5.0 Team! Yeah, that'll work! Osmium (aka Oz) - More and more Internet protocol work was poured into the product including LDAP v3 and NNTP support. It was also obvious that 16GB of database space was not enough. Exchange 5.5 was born and shipped near the end of '97. Platinum (aka Pt) - After we shipped Exchange 5.5, we started building the Exchange 6.0 product. Big changes were afoot. The Exchange Directory team had moved over to Windows and Active Directory was coming together. Both the Windows and Office teams used year numbers for their releases, so externally, the product would be called '2000' rather than 6.0. There was no point changing the internal version numbers, so we stuck with 6.0 inside the code. Exchange 2000 was released in November of the year 2000. Mercury - Exchange 2000 also turned out to be a little rough around the edges, especially with upgrades and integration with Exchange 5.5. We had to act quickly, so SP1 quickly followed. However, more was needed, so we started work on a 6.1 which was codenamed 'Mercury'. Ironically, this was the same code name as what we had used back in the early 90's, and suffered the same fate as the first Mercury. For various business reasons, the Mercury project was canceled. We had already written a lot of new code, and this was eventually divided and shipped as part of Exchange 2000 SP2 + SP3, with the rest in Titanium. Titanium (Ti) - We were now working on Exchange 6.5, this was to sync up with Windows 2003 and Office 2003. Major technical breakthroughs occurred in this release including the advent of RPC/HTTP, cached mode and ActiveSync for mobile clients. Exchange 6.5 was externally shipped as Exchange 2003 (shipped in September of 2003). Kodiak - after Exchange 2003 shipped, it was time for a major shake-up of the product. We had many new ideas and needed a place to check-in our code - the version number is now 7.0. Spam is a major problem – is it time to create a special version of Exchange just to tackle this? The small business market is in need of a 'tiny' version of Exchange – perhaps the market is ripe for Exchange for Workgroups, or perhaps Exchange Express. For the enterprise product, is it time to switch from ESE (JET) to SQL? After a lot of research and investigation, we decided to cancel the Kodiak project, but take our best ideas forward. E12 - A new version of Exchange needs to come together. There's too much proof-of-concept code occupying the 7.0 version space. It's time to increment to 8.0. With major changes all round, including Unified Messaging, multiple server roles and PowerShell integration, the code name was aligned with the Office team. Office was working on their '12' wave, and so we used the code name of Exchange 12 (or E12). Exchange 8.0 / E12 was externally shipped as Exchange 2007 at the end of year 2006. E?? - We just shipped Exchange 2007 SP1 (or, E12 SP1 to you and me). What's next, you ask? Is it Exchange 9.0 or perhaps Exchange 13? Perhaps it's something completely different... Stay tuned! Paul Bowden15 years!
Believe it or not – as of today, this blog has been around for 15 years! That’s right… the very First post was published on February 9, 2004, with How the M: Drive came about hot on its heels. Not too shabby for something people said would never work! On this blog, we have something about every version of Exchange since Exchange 5.5; we headed off to the cloud with Exchange Online and we came back to earth recently announcing Exchange Server 2019. We dove into history with posts like A brief history of time – Exchange Server way as well as explained The story of Squeaky Lobster. Oh, and we also covered a bunch of technical stuff too, from time to time. Have you ever wondered what the top 5 posts that people viewed on the blog have been (each of them with over 300,000 page views)? Well, here they are: Ask the Perf Guy: Sizing Exchange 2013 Deployments GAL Photos in Exchange 2010 and Outlook 2010 Outlook Connectivity with MAPI over HTTP Want more control over Sent Items when using shared mailboxes? Configure Automatic Replies for a user in Exchange 2010 And did you know that we have had over 40M page views for content on our blog? 40M! Truth is, we suspect this number to be higher but over the years, as blog home has changed, different platforms tracked this differently so it’s a bit of a mystery. Did you know that we had our blog officially translated into 10 languages for a few years (though sadly most of those are now gone (translated blog posts, not the languages))? All of this would not have been possible if it was not for people writing stuff for the blog. The process that we go through when posting has not changed very much over the years but it always starts with an idea and someone willing to write about it. They are not always the same person. We don’t have an exact number but we have had 300+ people contribute to the blog by authoring blog posts. We’ve had Support Engineers, engineering PMs and Devs, the Marketing team, Consultants, Escalation Engineers and we probably missed about 10 more titles – all of whom have dedicated time to research and write stuff to share it with Exchange community. We also had many more people commenting and providing feedback, both from inside Microsoft and from our loyal readers and fans. Blogging was never really anyone’s job, so having ideas and finding people willing to write about them is what made this possible. We realize that over the years (because we are now old and wise, in a Santa Claus kind of way), the way people consume information (and where they do it) have changed, but as we still seem to have a good sized following, we plan to keep this thing going. As mentioned, over the years we have moved our blog between different platforms (the current platform is platform #4) and we are considering moving again, which will help us be more plugged into overall Microsoft blogging / community efforts. Don’t you worry, if we do something, we plan to bring our content with us and work on redirection of old URLs to their new home. But more on that later; let’s spend our time today celebrating the past, why care about the future, we say. For today, anyway! We have been doing a bit of cleanup, though. You might notice that bios (that we used to post for post authors) have been deleted. Honestly – over the years this stuff became so hopelessly out of date that it just needed to go. Trying to update someone’s bio from 10 years ago is just not all that interesting. Anyway – as we remember the past and muse about the future – we wanted to ask a few questions, hoping to get a bit more insight into how you would like us to continue with this blog of ours: Do you still find information in the form of a blog post something that you use? Why would you prefer something to be a blog post vs. let’s say a documentation article? Any other tips you have for us? The Exchange Team Blog Team
