That's good to hear that you're on it. I did encounter and resolve something that may be of interest. Within Outlook, I dragged an existing contact into the DNN contacts folder. At some point it synched with DNN. When I attempted to open/edit in DNN, DNN threw a permissions error stating that it could not access the correct portal\users\ subfolder. I then looked at permissions on my server, and started adding permissions. Eventually I was able to fix it, which allowed me to open the record on DNN, but I cant tell you precisely which account/permission did the trick.

This is something strange going on, and we have not worked it out yet.

We have seen DNN fail at this, but not always. Sometimes it works and sometimes not, making it very hard to find the culprit within DNN. We are still working to improve this.

FIXED!!

I decided to start entering the new names through DNN directly, but I found out that the "Display Name" was causing the entry to be rejected because it already existed. So I went into  Admin/Site Settings/User Account Settings  and unchecked "Require Unique Display Name". I thought this might cause Outlook Sync some problems, so instead of continuing to try direct DNN entry, I went back to Outlook and tried to enter a new person. At first it didn't work, but then I went back to DNN and through the Host login did a Tools/Clear Cache  and a  Tools/Recycle Application Pool. Went back to Outlook and did a Send/Receive and the new entry was in the list!

So maybe a new version of Outllook Sync will be able to handle the error DNN generates when the user's first name is rejected as a Display Name because the Admin settings are set to require a unique display name. Maybe it could try some more names, like adding digits or adding a few letters of their last name and trying again until there was not an error, or until some pre-set number of retries has elapsed. Yes?
Just a thought.

So far, pretty good. I had about 17 people I couldn't enter. Turns out they all had first names like Diane, Barbara, Nancy, etc., that were already being used as display names in the system. Turning off the Unique Display Names requirement allowed me to enter all of them. However, they did not always update on the server right away. You can see this right on Outlook in Phone List view if you display the Categories column and have that set up on the server. It remains blank for new entries until the server is updated, then it shows the Security Roles that they are assigned on the DNN server.

I usually used the "Save and New" button in Outlook (2007) and noticed that the Categories column was blank for the just entered previous item. As I wen along, though it got filled in, so eventually all the items appeared on the server, except for the last one I had entered. It still wasn't on the server.

I tried several things including editing the item to add a space to the name and then delete it before I saved it. That didn't work. Eventually, I added a fictitious phone number to the item and saved. That actually worked. Then I edited the item again to delete the phone number. I went into Mail and did Send/Receive each time, but often it didn't update the server. Then I waited about 15 minutes and checked on the server to see if the bogus phone number was still in the record. It was. So having waited that 15 minutes, I did a Send/Receive in Outlook then checked the server again. The bogus phone number was gone!

I know they tell you that SharePoint lists get updated in a strange schedule that is supposed to minimize too much traffic or something like that, but this is just weird. The net result is that everything worked, but the last item was a difficult one to get updated. On my localhost, it is never a problem. On the production server I don't remember it being a problem either until this issue with duplicate first names arose which are being used as the Display Names. Somehow, I get the feeling that is causing delays in getting these new records with duplicate first names updated. Eventually it all did get updated though.

Hope that helps you.

We are listening and working with a fix. Still not final though, but as soon as we have something we will let you know.