Copying Proxy-Addresses to Another Forest

  • 1K Views
  • Last Post 11 March 2015
SamErde posted this 18 February 2015

Here's a fun one for you guys:
I've been given a requirement to get an LDAP "integrated" secure email application working in our environment. This application looks at the Proxy-Addresses attribute and uses the primary SMPT address as the user's ID for logging into the application. The problem is that we have an Exchange resource forest, which is where the mailbox accounts [disabled] hold the Proxy-Addresses attribute. The linked master accounts [enabled] in our 3 user forests have the passwords...so I have a fun challenge. (Note, we should have all of the users in 1 forest by April, but it will be some time before we are able to migrate Exchange out of the resource forest.) 
In lieu of waiting for our forest consolidation project to be completed, I'm looking at ways to "sync" the Proxy-Addresses value to users' AD accounts. Without a full FIM installation, the two options that I can think of are (1) use PowerShell to export a CSV from the Exchange resource forest and then import the information to the user forest, or (2) use ADMT to "migrate"/merge the accounts, only bringing over that 1 attribute (more or less).
I'm leaning towards the first approach, similar to what that our friend the Scripting Guy demonstrated on his blog: 
http://blogs.technet.com/b/heyscriptingguy/archive/2005/05/10/hey-scripting-guy-how-can-i-add-an-email-address-to-the-proxyaddresses-attribute.aspx
Thoughts?
Thanks!
Sam

Order By: Standard | Newest | Votes
SamErde posted this 05 March 2015

I ended up writing a PowerShell script to copy my users' ProxyAddresses attribute from the Exchange resource forest account to their linked master account in varied user forests. (One resource forest and 3 user forests.)
The script runs from a management server in a forest that is trusted (1-way) by every other forest in my organization. It creates a remote session on the Exchange server, pulls every relevant recipient into an array, and then loops through that array to copy the ProxyAddresses to the linked user accounts.
If anyone is interested in a copy of this, let me know. As a relative novice with PowerShell, I'm working on ways to make it accept parameters and not have to hard-code some of the domain information. Feedback would be welcome! 
Sam


show

zhiaga posted this 05 March 2015

Hi
Please send it to me, I am very interested because I have the same configuration of exchange
Thx!!!!


De: Sam Erde <samuel.erde@xxxxxxxxxxxxxxxx>
Para: ActiveDir List <ActiveDir@xxxxxxxxxxxxxxxx>
Enviado: Jueves, 5 de marzo, 2015 13:59:31
Asunto: Re: [ActiveDir] Copying Proxy-Addresses to Another Forest

I ended up writing a PowerShell script to copy my users' ProxyAddresses attribute from the Exchange resource forest account to their linked master account in varied user forests. (One resource forest and 3 user forests.)
The script runs from a management server in a forest that is trusted (1-way) by every other forest in my organization. It creates a remote session on the Exchange server, pulls every relevant recipient into an array, and then loops through that array to copy the ProxyAddresses to the linked user accounts.
If anyone is interested in a copy of this, let me know. As a relative novice with PowerShell, I'm working on ways to make it accept parameters and not have to hard-code some of the domain information. Feedback would be welcome! 
Sam


show

robertsingers posted this 06 March 2015

By not hard code the domain do you just mean use "$env:userdomain" or
do you mean something else?

show

anandh11.v posted this 06 March 2015

Please share the script even I'm looking something like that as well
Anand
On Friday 6 March 2015, Robert Singers <rsmsingers@xxxxxxxxxxxxxxxx> wrote:
By not hard code the domain do you just mean use "$env:userdomain" or


do you mean something else?


show

SamErde posted this 06 March 2015

Guys, I'll try to have the script ready to share early next week. I have been re-writing some parts of it to eliminate references to my corporate domain names and controllers. I'm nearly done working on a new approach that won't require anything in the script to be manually coded except for a few variables at the start of the script. (@Robert, that's what I meant by "hard coded.")
The basic pseudo-code structure is:

  1. Import the Active Directory Module.
  2. Specify the name of your Exchange server to query recipients from.
  3. Provide a list of domain names that you know you'll be working with, including both their DNS domain name and their NetBIOS domain name. These are stored in an array for each domain.
  4. Create a hash table that includes the domain names array in the key, and the FDQN of a freshly-discovered domain controller in the value. This may be over-complex for the given problem, but it allows the rest of the script to be run without needing to manually specify domain and server information again.
  5. Create a remote session on the Exchange server (prompt for credentials).
  6. Create an array with a list of all recipients that have a valid linked master account (excluding mailboxes with a linkedMasterAccount attribute that is blank, an unresolved SID, or is "NT_AUTHORITY\SELF).
  7. Each item in the array stores the linkedMasterAccount name and the emailAddresses attribute (ProxyAddresses).
  8. Use the Split method to identify the linkedMasterAccount user's NetBIOS domain name (Exchange stores this as DOMAIN\UserName).
  9. Use the hash table above to match the NetBIOS domain names to their DNS domain names and a domain controller name.
  10. Run the Set-ADUser commandlet to replace the ProxyAddress attribute on the user's linkedMasterAccount. I reference the hash table created above to specify the right name for the -Server parameter.
I had another idea to actually discover the linked user domain names and not require the admin to enter domain names as array variables, but that's for another day where I have more time to learn as I code. It would look like this, skipping step 3 above: 
  1. Pull the list of Exchange recipients with valid linkedMasterAccount values in them.
  2. Go through the list of recipients again, finding all unique NetBIOS domain name values from that attribute, and save them in another array.
  3. We need the DNS domain name, so we would query AD for a list of trusts, match the NetBIOS domain name from the recipients list with the "flatName" attribute of each trust, and then pull the DNS domain name from the information in that trust.
  4. This will allow us to programmatically find all of the necessary domain names and server names to complete the Set-ADUser command.

More soon. Thanks!
Sam


show

SamErde posted this 11 March 2015

As requested, here is a link to my script. For people with an Exchange resource forest and separate user forest[s], this script copies the ProxyAddresses (emailAddresses) attribute from the user's linked mailbox account to their linkedMasterAccount in the user forest. This is useful when an application is looking for email addresses to be set on the users' Active Directory accounts.
https://www.dropbox.com/s/ok5jhewwx6hpqxz/copy-proxyaddresses.ps1
You should be able to run this script from your Exchange resource forest. In my case, I ran it from a user forest that is trusted by all other forests in my environment (with 1-way incoming trusts).
In order to use it, you will need to modify 2 variables at the top of the script. 

  1. The first is a variable ($exchangeFQDN) that stores the name of the Exchange server that you will be querying recipients from. 
  2. The second variable ($userDomains) is a little more complex: it is an array of arrays. Use this array to create a list of domains that your user accounts live in. (The ones that have linked mailbox accounts in the resource forest.) Each array in this variable must contain two items: the first is the DNS domain name and the second is the NetBIOS domain name of the user's domain.
The rest of the script should work as-is. I use both forms of the domain name above because Exchange links mailboxes to the user's account using the NetBIOS domain name and the samAccountName. The Set-ADUser command at the end of the script requires us to know the DNS domain name (more specifically, a domain controller name), and so a way to match these up is required.
I'm sure that you'll find ways to improve this script, so please feel free to do so. If there's already a different way to do this with freely available Exchange migration tools...well, then this was good practice for an aspiring PowerShell admin.
Cheers!Sam


show

Close