2 problems (editing Contact objects and disappearing entries in addressbook)

[Brandon McCombs]

Hello,

I have 2 unrelated(I hope) issues. One of which I have first hand proof
of the problem and the other is just reported to me through a 3rd party.

1. On a win2k3 system with AD installed we have about 30,000 contact
objects in a particular OU but the objects are spread over another 50 or
so OUs under the main one. Initially this worked just fine and regular
users could update this information using a customized ADUC snap-in
created with the MMC custom taskpad wizard. Recently I've gotten
reports from users that when they go to edit a Contact object in the
aforementioned OU and click Apply/OK the custom taskpad window locks up
and they have to End Task the process. The change they made does indeed
take effect as can be seen when they open the taskpad again and view the
contact.

I have a small test environment setup with the same list of contacts and
recently (last week sometime) I ran into this same problem and I was
using the default ADUC snapin provided by MS. Since I could duplicate I
started narrowing down the circumstances. It seems the issue only
occurs when I edit contact objects (user objects can be edited just
fine) and the contacts can be anywhere in the directory structure (in
the aforementioned OU or in another OU that isn't a subtree of the
former one). When the problem crops up the MMC binary chews up about 5
megs every second and will keep going and cause other programs to swap
out. End tasking the mmc binary is the only way to free the memory and
reopening the MMC shows the change I did really did take effect.

I've looked online to see if any bugs exist that seem to show these
symptoms but haven't found anything. Any ideas?



2. The other problem is that users are reporting that these same
contacts seem to disappear one day (some disappear, not all) and the
very next day they can reappear. They use Outlook 2000 with Exchange
accounts and are viewing the contacts through the Outlook Address Book.
Is that possible (I haven't seen proof for myself yet) and if so under
what circumstances? thanks again

 

[Ace Fekay [MVP]]

In

Hello,

I have 2 unrelated(I hope) issues. One of which I have first hand
proof of the problem and the other is just reported to me through a
3rd party.
1. On a win2k3 system with AD installed we have about 30,000 contact
objects in a particular OU but the objects are spread over another 50
or so OUs under the main one. Initially this worked just fine and
regular users could update this information using a customized ADUC
snap-in created with the MMC custom taskpad wizard. Recently I've
gotten reports from users that when they go to edit a Contact object
in the aforementioned OU and click Apply/OK the custom taskpad window
locks up and they have to End Task the process. The change they made
does indeed take effect as can be seen when they open the taskpad
again and view the contact.

I have a small test environment setup with the same list of contacts
and recently (last week sometime) I ran into this same problem and I
was using the default ADUC snapin provided by MS. Since I could
duplicate I started narrowing down the circumstances. It seems the
issue only occurs when I edit contact objects (user objects can be
edited just fine) and the contacts can be anywhere in the directory
structure (in the aforementioned OU or in another OU that isn't a
subtree of the former one). When the problem crops up the MMC binary
chews up about 5 megs every second and will keep going and cause
other programs to swap out. End tasking the mmc binary is the only
way to free the memory and reopening the MMC shows the change I did
really did take effect.
I've looked online to see if any bugs exist that seem to show these
symptoms but haven't found anything. Any ideas?



2. The other problem is that users are reporting that these same
contacts seem to disappear one day (some disappear, not all) and the
very next day they can reappear. They use Outlook 2000 with Exchange
accounts and are viewing the contacts through the Outlook Address
Book. Is that possible (I haven't seen proof for myself yet) and if
so under what circumstances? thanks again

I have not heard about contacts locking up an MMC, but the only basic thing
I have questions about are what SP level are the Win2k3 DCs and which admin
pack did you install on the XP (min SP1) clients (no Windows 2000 Pro)?
Win2003 SP1 admin pack has an updated version of the admin tools compared to
the RTM.

Also, I am assuming that your AD infrastructure doesn't have any problems
with replication and GC availability?

As for Outlook 2000, the only thing I can think of is I believe you may need
the latest Outlook service pack for it and fixes, but I don't remember
exactly and I don't have a reference for that article that I read that in.
--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

If you are having difficulty in reading or finding responses to your post,
instead of the website you are using, if I may suggest to use OEx (Outlook
Express or any other newsreader of your choosing), and configure a newsgroup
account, pointing to news.microsoft.com. This is a direct link into the
Microsoft Public Newsgroups, and it is FREE and DOES NOT require a Usenet
account with your ISP. With OEx, you can easily find your post, track
threads, cross-post, and sort by date, poster's name, watched threads or
subject.

Not sure how? It's easy:
How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Windows Server Directory Services
Microsoft Certified Trainer
Assimilation Imminent. Resistance is Futile.
Infinite Diversities in Infinite Combinations.
=================================

 

[Brandon McCombs]

In

I have not heard about contacts locking up an MMC, but the only basic thing
I have questions about are what SP level are the Win2k3 DCs and which admin

Sorry, for to mention some of those details. The DCs currently do not
have SP1 installed. That is scheduled to be installed this weekend.

pack did you install on the XP (min SP1) clients (no Windows 2000 Pro)?

XP with SP2 (no win2k machines at all)

Win2003 SP1 admin pack has an updated version of the admin tools compared to
the RTM.

DO we need to upgrade based on the info I provided to your questions
above or are we at a new enough patch level that it isn't an issue?

Also, I am assuming that your AD infrastructure doesn't have any problems
with replication and GC availability?

No, as far as I know things are okay. I work as a subcontractor on a
development contract and a different group of people work as
subcontractors on the ongoing maintenance contract so I have to rely on
them to say anything (they don't expect me to fix them though, they just
let me know in case I might know what the solutions are but it's mainly
their job) and I haven't heard them say anything about replication. We
do however only have 1 of the DCs as a GC. Would making them both a GC
help? We have 500 users.

As for Outlook 2000, the only thing I can think of is I believe you may need
the latest Outlook service pack for it and fixes, but I don't remember
exactly and I don't have a reference for that article that I read that in.

Ok. I'll look into that tomorrow. Thanks for your time.

 

[Ace Fekay [MVP]]

In

Sorry, for to mention some of those details. The DCs currently do not
have SP1 installed. That is scheduled to be installed this weekend.


XP with SP2 (no win2k machines at all)


DO we need to upgrade based on the info I provided to your questions
above or are we at a new enough patch level that it isn't an issue?

I would try to upgrade everything, because there may be different
features/internal differences in the service pack level admin tools. If you
upgrade a 2003 server to SP1, I would then upgrade the workstation admin
pack tools as well (or just the DLLs from the new admin pack components,
depending on how you set them up), to keep them on the same 'page'.

When I create an MMC for my customers' specific users, if it's just an MMC
to have access to a specific OU and no other AD components, I would just
copy adprop.dll and dsadmin.dll to the workstation, remotely register them
using Psexec and the regsvr32 command (eg. regsvr32 adprop.dll), and then
remotely copy the msc file to the person's desktop in their specific
profile. If I were upgrading them, I would first unregister those two files
(regsvr32 /u adprop.dll, etc) and copy the new ones over, and then register
them again. You can also script it if there are multiple users.

No, as far as I know things are okay. I work as a subcontractor on a
development contract and a different group of people work as
subcontractors on the ongoing maintenance contract so I have to rely
on them to say anything (they don't expect me to fix them though,
they just let me know in case I might know what the solutions are but
it's mainly their job) and I haven't heard them say anything about
replication. We do however only have 1 of the DCs as a GC. Would
making them both a GC help? We have 500 users.

Maybe that may help and be prudent (depending on your design because in a
multi domain environment, the GC can't be on an IM). If that doesn't work
(which I'm leaning towards that it may not), I would look into the OUtlook
thing and the service pack levels.

Ok. I'll look into that tomorrow. Thanks for your time.

Good luck!

Ace

 

[Brandon McCombs]

In

I would try to upgrade everything, because there may be different
features/internal differences in the service pack level admin tools. If you
upgrade a 2003 server to SP1, I would then upgrade the workstation admin
pack tools as well (or just the DLLs from the new admin pack components,
depending on how you set them up), to keep them on the same 'page'.

When I create an MMC for my customers' specific users, if it's just an MMC
to have access to a specific OU and no other AD components, I would just
copy adprop.dll and dsadmin.dll to the workstation, remotely register them
using Psexec and the regsvr32 command (eg. regsvr32 adprop.dll), and then
remotely copy the msc file to the person's desktop in their specific
profile. If I were upgrading them, I would first unregister those two files
(regsvr32 /u adprop.dll, etc) and copy the new ones over, and then register
them again. You can also script it if there are multiple users.

We did exactly your same procedure when we deployed the msc file. We
gave them the 2 files you mentioned and registered them. I don't know
what version of the files we gave them though (files for SP1 or prior to
that but if I had to guess I'd say we gave them the right ones because
we probably didn't have the SP1 version anywhere). Somehow I think what
I'm running into is a bug in the msc or mmc since AD is supposed to be
capable of housing millions of objects (although I'm sure that isn't all
on the same server) and besides, the error only occurs on Contact
objects so if it was a capacity issue then user objects would cause the
same problem.

Maybe that may help and be prudent (depending on your design because in a
multi domain environment, the GC can't be on an IM). If that doesn't work
(which I'm leaning towards that it may not), I would look into the OUtlook
thing and the service pack levels.

I found out today that office xp is installed if that helps any. I'll
keep investigating. Thanks for your help again.

 

[Ace Fekay [MVP]]

In

We did exactly your same procedure when we deployed the msc file. We
gave them the 2 files you mentioned and registered them. I don't know
what version of the files we gave them though (files for SP1 or prior
to that but if I had to guess I'd say we gave them the right ones
because we probably didn't have the SP1 version anywhere).

Interesting you did it this way, for not too many are aware of this method.
I like it because I don;t have to install the whole adminpak with the extra
stuff installed on a delegated user's machine. If upgrading the DCs to SP1,
SP1 provides newer versions of these files (and the adminpak) in the DC's
system32 folder. Copy them over.

Somehow I
think what I'm running into is a bug in the msc or mmc since AD is
supposed to be capable of housing millions of objects (although I'm
sure that isn't all on the same server) and besides, the error only
occurs on Contact objects so if it was a capacity issue then user
objects would cause the same problem.

An AD forest (whether one domain or hundreds of domains) will support 4.3
billion objects. No company I know of has anywhere near that, so capacity is
not an issue here. Not sure about any bugs, unless after upgrading them and
the prob disappears, then so be it.

One other thing to look at is exactly what were the users delegated? Only
users objects or contacts as well?

Do you have Exchange installed? Are the Contacts mail-enabled?

No errors on the GCs? If Exchange, any DSAccess errors in Exchange's Event
logs? (indicative of GC probs).

I found out today that office xp is installed if that helps any. I'll
keep investigating. Thanks for your help again.

This is guesswork, but I hope our deducing this and breaking it down may
help, unless it's something else that we are both not aware of that was done
or is running in the enironment.

Ace

 

[Brandon McCombs]

In

Interesting you did it this way, for not too many are aware of this method.
I like it because I don;t have to install the whole adminpak with the extra
stuff installed on a delegated user's machine. If upgrading the DCs to SP1,
SP1 provides newer versions of these files (and the adminpak) in the DC's
system32 folder. Copy them over.

Well, regular users are restricted from having access to AD and AD tools
on regular user workstations are frowned upon so I wanted to allow a
group of like 5 people to update information in AD but wanted it to be
unobtrusive as possible so I spent time learning that when using the MS
Installer there are switches with adminpak.msi that allow you to choose
which snapins you really want and then I narrowed it down from there as
to which files were actually installed and figured out which ones were
really needed. It probably took me 2 or 3 hours to do if I remember
correctly.

An AD forest (whether one domain or hundreds of domains) will support 4.3
billion objects. No company I know of has anywhere near that, so capacity is
not an issue here. Not sure about any bugs, unless after upgrading them and

I remember reading about a site that had the largest recorded AD and I
forget what they did (I think webhosting or something) but they had a
few million objects in their AD.

At first I thought the mmc was caching all the contact object data but
when the same thing didnt happen with user objects I was baffled. By
the way, I have 2 DC instances running in VMware VMs and so far I
haven't had the same problem with editing the contact info and I've had
the data in there a long time(3+ months) (and even had one VM off long
enough that the tombstone lifetime got me 2 times and I had to force
replication with registry hack temporarily to get things replicating
again). At work the contact data has been in place since early Nov. 2005.

the prob disappears, then so be it.

One other thing to look at is exactly what were the users delegated? Only
users objects or contacts as well?

Strictly delegated to Contact objects and strictly in a certain OU
subtree. While we are on the topic of this I'll let you know about a
quirk (maybe even another bug) that I ran into when I was customizing th
e taskpad view. When you set a certain OU you want users confined to
seeing in the taskpad and you even turn off the Toolbar icons and menu
entries that let you get to Advanced Features(or VIew,I forget the name)
you can still actually get to Adv. Features by right clicking on an
entry. And if you do that then the user is knocked out of your little OU
"jail" and gets to see the whole directory again. Very annoying.

Do you have Exchange installed? Are the Contacts mail-enabled?

Yes Exchane 2003 on another set of 2 servers. Contacts have to be mail
enabled in this case so that they show up in the Outlook address book
(the same ones I mentioned in my 2nd problem).

No errors on the GCs? If Exchange, any DSAccess errors in Exchange's Event
logs? (indicative of GC probs).

I don't know. I'll have to see if one of the Admins can let me know
about it. I don't have any access to the operational environment and I'm
trying to do research on these things on my own time for my own
satisfaction because it bugs me. Don't count on me being able to find
out though because I know they have other things more important on their
ToDo list.

This is guesswork, but I hope our deducing this and breaking it down may
help, unless it's something else that we are both not aware of that was done
or is running in the enironment.

I'd be satisfied to find out they are both bugs and can be fixed (at
least the problem of the MMC freezing up) because then I'd have closure
and also a fix (hopefully).

 

[Ace Fekay [MVP]]

In

I remember reading about a site that had the largest recorded AD and I
forget what they did (I think webhosting or something) but they had a
few million objects in their AD.

Way below it's capacity!!!

At first I thought the mmc was caching all the contact object data but
when the same thing didnt happen with user objects I was baffled. By
the way, I have 2 DC instances running in VMware VMs and so far I
haven't had the same problem with editing the contact info and I've
had the data in there a long time(3+ months) (and even had one VM off
long enough that the tombstone lifetime got me 2 times and I had to
force replication with registry hack temporarily to get things
replicating again). At work the contact data has been in place since
early Nov. 2005.

Curious, can you post that reg entry?

Strictly delegated to Contact objects and strictly in a certain OU
subtree. While we are on the topic of this I'll let you know about a
quirk (maybe even another bug) that I ran into when I was customizing
th e taskpad view. When you set a certain OU you want users confined
to seeing in the taskpad and you even turn off the Toolbar icons and
menu entries that let you get to Advanced Features(or VIew,I forget
the name) you can still actually get to Adv. Features by right
clicking on an entry. And if you do that then the user is knocked out
of your little OU "jail" and gets to see the whole directory again.
Very annoying.

When I create a taskpad view, I remove EVERYTHING!! I uncheck all the
checkboxes. This way they do not have the rt-click context or can't go up
level.

I don't know. I'll have to see if one of the Admins can let me know
about it. I don't have any access to the operational environment and
I'm trying to do research on these things on my own time for my own
satisfaction because it bugs me. Don't count on me being able to find
out though because I know they have other things more important on
their ToDo list.

We'll need a little collaboration with those guys to help you out.

I don't think it's a bug. Just something else is up that maybe the admins
aren't saying. It's tough without the collaboration.

I'd be satisfied to find out they are both bugs and can be fixed (at
least the problem of the MMC freezing up) because then I'd have
closure and also a fix (hopefully).

I can understand that!

Ace

 

[Brandon McCombs]

In

Way below it's capacity!!!


Curious, can you post that reg entry?

HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Create a value called "Allow Replication With Divergent and Corrupt
Partner" as REG_DWORD type with data of 1. I do it on both of my VMs
and after waiting a little bit (not sure how long) and trying to force
replication in AD Sites and Services I no longer get errors.

When I create a taskpad view, I remove EVERYTHING!! I uncheck all the
checkboxes. This way they do not have the rt-click context or can't go up
level.

I think I tried that but could never get that working. I was going to
give users
buttons or something in the taskpad to create contact objects or to edit
them
but no matter what I did the right click menu was still accessible which
annoyed the hell out of me especially since it allowed access to other
things that I was trying to prevent. Maybe I was giving too much still
and it was enough to still allow the right click menu. I really don't
know. It frustrates me to even talk about it.

 

[Brandon McCombs]

I remembered something just after I hit Send. I tried the Exchange 2003
version of the ADUC snapin today and it still went haywire on my test
environment so if it's a bug then it's also in the Exchange version of
that snapin.

And another thing I just thought of: since I do have a test environment
of my own that is acting up I don't really have to rely on the other
guys to give me information about the operational environment. My
environment is for on going project work that I'm on so that's why I
have it. I'll check at work on Friday if I can remember and see if there
are any errors showing up in the logs. In that environment I have 1
machine that has Exchange and AD on it so no replication issues would
crop up on it. That's where I tried the Exchange AD snapin today (i've
mentioned the environment in previous posts in this thread).

 

[Ace Fekay [MVP]]

In

I remembered something just after I hit Send. I tried the Exchange
2003 version of the ADUC snapin today and it still went haywire on my
test environment so if it's a bug then it's also in the Exchange
version of that snapin.

And another thing I just thought of: since I do have a test
environment of my own that is acting up I don't really have to rely
on the other guys to give me information about the operational
environment. My environment is for on going project work that I'm on
so that's why I have it. I'll check at work on Friday if I can
remember and see if there are any errors showing up in the logs. In
that environment I have 1 machine that has Exchange and AD on it so
no replication issues would crop up on it. That's where I tried the
Exchange AD snapin today (i've mentioned the environment in previous
posts in this thread).

Ok. I will be kind of surprised if it's a bug, since I haven't heard of this
prior to now. Let me know what you find out.

Ace

 

[Ace Fekay [MVP]]

In

HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Create a value called "Allow Replication With Divergent and Corrupt
Partner" as REG_DWORD type with data of 1. I do it on both of my VMs
and after waiting a little bit (not sure how long) and trying to force
replication in AD Sites and Services I no longer get errors.
Thanks!

I think I tried that but could never get that working. I was going to
give users
buttons or something in the taskpad to create contact objects or to
edit them
but no matter what I did the right click menu was still accessible
which annoyed the hell out of me especially since it allowed access
to other things that I was trying to prevent. Maybe I was giving too
much still and it was enough to still allow the right click menu. I
really don't know. It frustrates me to even talk about it.

The last ones I created for one client, and one for each 'location' OU, I
left the rt-click context, and the tree view (left pane and right pane), but
I removed everything else including the file menu buttons and such. So under
View, Customize, uncheck everything except the top one that says Console
Tree. This way they can't go up level or click any of the things in there.
But they will have the rt-click feature.

Start/run/mmc enter
File/Add Remove Snap-in/Add ADUC
Drill down under the domain to the OU you want.
Rt-click on that OU, new window from here.
A new window pops up with the OU in the left pane and the contents in the
right pane.
Close the original ADUC window leaving the new window you just created.
Expand the window to take up the whole console.
Now they will not be able to go up levels and are 'stuck' in this OU.
View/Customize
Uncheck everything but Console Tree.
File/Options Choose Console Mode:
User mode: Limited Accessm single window
Check: Do not Save Changes to this console
Uncheck: Allow the user to customize views
Save it. Logon as a test user delegated whatever perms to do on those users
and test it.

If you want to eliminate the rt-clicking on a user account, uncheck the
Console Tree above and change the console view by rt-clicking on the OU,
choose New Task View, and choose a vertical or horizontal list, then choose
to create a new task, menu command, highlight a user account, choose reste
pasword, or anything else in the right column, choose an icon, and finish.

Ace

 

[Brandon McCombs]

In

Ok. I will be kind of surprised if it's a bug, since I haven't heard of this
prior to now. Let me know what you find out.

Ace

Today I created a new contact and edited it just fine so I decided to
delete the whole OU subtree that had these contacts and afterwards I
reloaded them (about 30,000 entries). I edited a contact while the data
was loading (after maybe 500 had got in) and it took a while to save
since it was processing the data being loaded but it eventually saved
just fine (after a few minutes I'd guess). I tried to edit a different
contact after they were all loaded and the damn thing did the same thing
to me. I don't know what happens. I looked at my logs and no errors
regarding the issue. AD, exchange, dns, and frs are all running fine and
it's only the mmc.exe binary that goes haywire. I don't know what else
to try.

 

[Ace Fekay [MVP]]

In

Today I created a new contact and edited it just fine so I decided to
delete the whole OU subtree that had these contacts and afterwards I
reloaded them (about 30,000 entries). I edited a contact while the
data was loading (after maybe 500 had got in) and it took a while to
save since it was processing the data being loaded but it eventually
saved just fine (after a few minutes I'd guess). I tried to edit a
different contact after they were all loaded and the damn thing did
the same thing to me. I don't know what happens. I looked at my logs
and no errors regarding the issue. AD, exchange, dns, and frs are all
running fine and it's only the mmc.exe binary that goes haywire. I
don't know what else to try.

So your saying your test results mean contacts imported and not manually
created is the problem child? If so, do a csvde export just on the object
you created and one of the ones imported and match the attributes. See
what's different.

Ace

 

[Brandon McCombs]

In

So your saying your test results mean contacts imported and not manually
created is the problem child? If so, do a csvde export just on the object
you created and one of the ones imported and match the attributes. See
what's different.

Ace

well not exactly because as they were importing I edited one of them and
it worked fine and then when they were done I edited another one and ran
into the problem again. I don't know what would be different during the
import compared to after but I'll do a csvde export in my virtual
machine setup since the problem exists there too and I'll see if i can
see anything wrong. I do know that all the entries are loaded with the
same default email address. I made it the same because it wasn't going
to be used but had to be set in order for Exchange to list them in the
address book. You think that is the problem? The GUI won't let you set
an email address for an entry when the address already is owned by
another entry.

 

[Brandon McCombs]

In

So your saying your test results mean contacts imported and not manually
created is the problem child? If so, do a csvde export just on the object
you created and one of the ones imported and match the attributes. See
what's different.

Ace

I just confirmed the email addresses were the problem. I changed one of
the addresses and then changed some other piece of data to make me click
Apply and it was okay after making the change. I went to change another
contact w/o making the address unique first and I ran into the memory
problem. As soon as I set the email address to something unique it
worked again so that is it. I'll have to let the guys know at work now.

thanks for your help.

 

[Ace Fekay [MVP]]

In

I just confirmed the email addresses were the problem. I changed one
of the addresses and then changed some other piece of data to make me
click Apply and it was okay after making the change. I went to change
another contact w/o making the address unique first and I ran into
the memory problem. As soon as I set the email address to something
unique it worked again so that is it. I'll have to let the guys know
at work now.
thanks for your help.

Email address duplicates. That makes sense. Glad you figured it out!

No problem for the help. I was curious from the first post what this could
be in case I ran into it!

Cheers!

Ace