Exchange 2010 External Contacts Address list from SQL Table
I asked this question in the SQL forum but didnt get much luck - perhaps you guys are smarter :) We have a home grown access front end / sql back end database. In this database we have store all of our clients in a contacts table. I would like to push integrate these contacts from this table into a Microsoft Exchange Address list. From what I have found the easiest way to do this is to first sync the contacts table with external contacts in active directory. After that building the address lists is failry simple. So the first part is getting the contacts table to sync with Active Directory - this should be something that can either sync automatically or with a task on a regular basis so that updates to the SQL database will also update Active Directory external contacts. Can anyone point me in the right direction. Either powershell, other other tools that are provide by MS or third party apps if all else fails. Thanks John
July 22nd, 2011 12:01pm

Hi, If you can export the sql list to a csv file you can create the contacts from this csv file. This should help http://social.technet.microsoft.com/Forums/en-GB/exchange2010/thread/d8c4f96b-9963-4f6b-b384-e1237acdcf93 Leif
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 1:47pm

On Fri, 22 Jul 2011 17:45:16 +0000, Leif Pedersen wrote: >If you can export the sql list to a csv file you can create the contacts from this csv file. Or just incorporate the SQL stuff right into the script and avoid the need for the intermediate CSV file. I'd go with the CSV file, though. It's a lot easier to deal with. :-) --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
July 22nd, 2011 6:05pm

Hi John, Any updates? Frank Wang
Free Windows Admin Tool Kit Click here and download it now
July 25th, 2011 3:35am

Still working on this - From the research I have done I would agree the best way to do this is to export table to CSV and then use powershell to create. I spent most of the day Friday trying to figure out the logic and the best way to do this because there isnt alot of guidance. One challenge will be updates to the SQL side. We will continue to use the SQL app for contacts - this is essentially our central repository for contacts. The problem will be updating existing contacts. On the SQL side I think I will have to add a field for last updated and field changed. Based on that I can create new with powershell, edit existing and then edit specific fields. I have a feeling this is going to be more complicated than I had hoped. Ideally it would be better if there was a way to sync directly. Like a connector of sorts. Then all the updates would be a non issue.
July 25th, 2011 10:00am

On Mon, 25 Jul 2011 13:54:44 +0000, dolejh wrote: > > >Still working on this - From the research I have done I would agree the best way to do this is to export table to CSV and then use powershell to create. > >I spent most of the day Friday trying to figure out the logic and the best way to do this because there isnt alot of guidance. > > > >One challenge will be updates to the SQL side. We will continue to use the SQL app for contacts - this is essentially our central repository for contacts. The problem will be updating existing contacts. > > > >On the SQL side I think I will have to add a field for last updated and field changed. > >Based on that I can create new with powershell, edit existing and then edit specific fields. > > > >I have a feeling this is going to be more complicated than I had hoped. > >Ideally it would be better if there was a way to sync directly. Like a connector of sorts. Then all the updates would be a non issue. That would be ADSI (or .Net) for the AD and ADO (or .Net) for the SQL. The code you use to update, or add, or delte, your database just makes the same changes in the AD at the same time. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
July 25th, 2011 5:21pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics