ADModify.NET is here!

Exchange-faq.dk - Din portal til Microsoft Exchange Server information

TrackBack — Thu, 05 Aug 2004 11:31:00 GMT

Exchange-faq.dk - Din portal til Microsoft Exchange Server information

re: ADModify.NET is here!

Ruben Jordà — Thu, 05 Aug 2004 08:50:00 GMT

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.

re: ADModify.NET is here!

Trouthunter — Thu, 05 Aug 2004 15:45:00 GMT

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?

re: ADModify.NET is here!

Raveendran Chinnasamy — Thu, 05 Aug 2004 16:19:00 GMT

I have used ADMODIFY extensively and it has to be included as Support tool like EXMERGE .

re: ADModify.NET is here!

Dan Winter — Thu, 05 Aug 2004 18:55:00 GMT

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...

re: ADModify.NET is here!

Trouthunter — Thu, 05 Aug 2004 20:54:00 GMT

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!

re: ADModify.NET is here!

Dan Winter — Fri, 06 Aug 2004 20:28:00 GMT

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.

re: ADModify.NET is here!

Mike R. — Fri, 20 Aug 2004 15:25:00 GMT

Can someone tell me what attributes are cleared using the "Kill Mail Attributes" checkbox?

re: ADModify.NET is here!

Dan Winter — Sat, 21 Aug 2004 15:29:00 GMT

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"

Terminal Server Profile options

Rory B — Tue, 24 Aug 2004 15:52:00 GMT

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?

re: ADModify.NET is here!

Marc Nivens — Wed, 25 Aug 2004 04:49:00 GMT

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.

re: ADModify.NET is here!

Rory B — Wed, 25 Aug 2004 18:34:00 GMT

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.

re: ADModify.NET is here!

Marc Nivens — Thu, 26 Aug 2004 02:39:00 GMT

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-3e44523f32e2 as this is where we post the latest version of the tool.

re: ADModify.NET is here!

Rory B — Thu, 26 Aug 2004 02:44:00 GMT

Marc...Thanks alot for your help. I look forward to the next release. Again, thanks!!