Folder security properties slow to resolve SID's to user ID names

[Microsoft Public Newsgroups]

We just recently did an in-place upgrade of our single NT4 Domain to a
single W2K3 AD Domain. Since that we've noticed that when we check the
security properties of a network folder from a client PC it takes forever to
resolve SID's to user ID's, particularly on folder with many sub-folders
beneath. Prior to the AD Domain this took less than a minute, and now it
takes up to ten minutes to completely resolve every last SID. Can anyone
give me some pointers on this? Thanks in advance.

PJ.

 

[Ace Fekay [MVP]]

In

We just recently did an in-place upgrade of our single NT4 Domain to a
single W2K3 AD Domain. Since that we've noticed that when we check
the security properties of a network folder from a client PC it takes
forever to resolve SID's to user ID's, particularly on folder with
many sub-folders beneath. Prior to the AD Domain this took less than
a minute, and now it takes up to ten minutes to completely resolve
every last SID. Can anyone give me some pointers on this? Thanks in
advance.
PJ.

Since no configuration information was provided, it is difficult to diagnose
without guessing. We can go over a few things that can cause this, but it
would be beneficial to know your configuration (ipconfig, AD DNS domain
name, remote sites, multiple domains, etc).

First thing that comes to mind is a client side DNS configuration issue. I'm
sure that part of the upgrade plan you installed DNS (part of the dcpromo
process if you didn't do it manually) and are now only using your new domain
controller for the DNS address of ALL internal machines. If you are using an
ISP's, or mixing ISP's and the internal DNS, that can cause numerous issues
with AD communication.

The other thing that comes to mind is that when you upgraded to AD from NT4,
that an incorrect, or more specifically, a single label name AD DNS domain
name was chosen. An incorrect example of such is "DOMAIN", whereas a correct
choice would have been "domain.com", "domain.net", "domain.local", etc.

Another issue that can cause this (either in conjunction with the above
issues or as a stand alone issue) is the DC has multiple NICs. Multiple NICs
are not recommended with DCs. However there are steps to configure a DC in
such a configuration, albeit not recommended.

To better assist, if you can post an ipconfig /all (unedited please) of your
DC and of an example client machine, (along with anything else that may be
pertinent), it will give us a great start in providing a diagnosis.

Thanks,

--
Ace

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

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.

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 - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only thing in life is change. Anything more is a blackhole consuming
unnecessary energy. - [Me]

 

[Microsoft Public Newsgroups]

From a client standpoint IPCONFIG /ALL looks like this:

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : imgsvr2
Primary DNS Suffix . . . . . . . : empire.corp
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : empire.corp

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : empire.corp
Description . . . . . . . . . . . : Intel(R) PRO/100 VM Network
Connection
Physical Address. . . . . . . . . : 00-08-02-A9-5A-86
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 163.2.5.28
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 163.2.100.2
DNS Servers . . . . . . . . . . . : 163.2.3.4
163.2.3.1
Primary WINS Server . . . . . . . : 163.2.3.1
Secondary WINS Server . . . . . . : 163.2.3.4

On the Domain and DC, configurations is as follows:

Single Domain, single site ... we have some remote sites still running NT4
BDC's (to be upgraded soon).
One DC (DC#1) is primary DNS and other DC (DC#2) is secondary DNS server.
Secondary DNS server (DC#2) is primary WINS, primary DNS (DC#1) is secondary
WINS.
Primary DNS (DC#1) is DHCP server providing all the usual info (DNS, WINS,
gateway, domain, time source, etc.)
Domain DNS name is empire.corp.
Both DC's have 2 NIC's but only one used ... second NIC is disabled in both.
Network is a single Class B IP sub-net ... no routing, except to remote
sites.
All other aspects of the Windows network (including remote BDC's) are
working fine.

IPCONFIG /ALL from DC#1:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CHOADCSVR01
Primary Dns Suffix . . . . . . . : empire.corp
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : empire.corp

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : HP NC7781 Gigabit Server Adapter
Physical Address. . . . . . . . . : 00-16-35-C2-F1-A6
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 163.2.3.4
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 163.2.100.2
DNS Servers . . . . . . . . . . . : 163.2.3.4
163.2.3.1
198.235.216.130
198.235.216.131
Primary WINS Server . . . . . . . : 163.2.3.1
Secondary WINS Server . . . . . . : 163.2.3.4

Those 198.235.216.nnn DNS addresses are our ISP's DNS server, to resolve
addresses for machines not on our network (i.e. the Internet), so our time
server (DC#1) can find the time sources.

If you need anything else please let me know. Thanks.

PJ.

In

We just recently did an in-place upgrade of our single NT4 Domain to a
single W2K3 AD Domain. Since that we've noticed that when we check
the security properties of a network folder from a client PC it takes
forever to resolve SID's to user ID's, particularly on folder with
many sub-folders beneath. Prior to the AD Domain this took less than
a minute, and now it takes up to ten minutes to completely resolve
every last SID. Can anyone give me some pointers on this? Thanks in
advance.
PJ.

Since no configuration information was provided, it is difficult to
diagnose without guessing. We can go over a few things that can cause
this, but it would be beneficial to know your configuration (ipconfig, AD
DNS domain name, remote sites, multiple domains, etc).

First thing that comes to mind is a client side DNS configuration issue.
I'm sure that part of the upgrade plan you installed DNS (part of the
dcpromo process if you didn't do it manually) and are now only using your
new domain controller for the DNS address of ALL internal machines. If you
are using an ISP's, or mixing ISP's and the internal DNS, that can cause
numerous issues with AD communication.

The other thing that comes to mind is that when you upgraded to AD from
NT4, that an incorrect, or more specifically, a single label name AD DNS
domain name was chosen. An incorrect example of such is "DOMAIN", whereas
a correct choice would have been "domain.com", "domain.net",
"domain.local", etc.

Another issue that can cause this (either in conjunction with the above
issues or as a stand alone issue) is the DC has multiple NICs. Multiple
NICs are not recommended with DCs. However there are steps to configure a
DC in such a configuration, albeit not recommended.

To better assist, if you can post an ipconfig /all (unedited please) of
your DC and of an example client machine, (along with anything else that
may be pertinent), it will give us a great start in providing a diagnosis.

Thanks,

--
Ace

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

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows
you to easily find, track threads, cross-post, sort by date, poster's
name, watched threads or subject.

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 - Directory Services
Microsoft Certified Trainer

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only thing in life is change. Anything more is a blackhole consuming
unnecessary energy. - [Me]

 

[Ace Fekay [MVP]]

In

From a client standpoint IPCONFIG /ALL looks like this:

Windows 2000 IP Configuration

Host Name . . . . . . . . . . . . : imgsvr2
Primary DNS Suffix . . . . . . . : empire.corp
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : empire.corp

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : empire.corp
Description . . . . . . . . . . . : Intel(R) PRO/100 VM Network
Connection
Physical Address. . . . . . . . . : 00-08-02-A9-5A-86
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 163.2.5.28
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 163.2.100.2
DNS Servers . . . . . . . . . . . : 163.2.3.4
163.2.3.1
Primary WINS Server . . . . . . . : 163.2.3.1
Secondary WINS Server . . . . . . : 163.2.3.4

On the Domain and DC, configurations is as follows:

Single Domain, single site ... we have some remote sites still
running NT4 BDC's (to be upgraded soon).
One DC (DC#1) is primary DNS and other DC (DC#2) is secondary DNS
server. Secondary DNS server (DC#2) is primary WINS, primary DNS
(DC#1) is secondary WINS.
Primary DNS (DC#1) is DHCP server providing all the usual info (DNS,
WINS, gateway, domain, time source, etc.)
Domain DNS name is empire.corp.
Both DC's have 2 NIC's but only one used ... second NIC is disabled
in both. Network is a single Class B IP sub-net ... no routing,
except to remote sites.
All other aspects of the Windows network (including remote BDC's) are
working fine.

IPCONFIG /ALL from DC#1:

Windows IP Configuration

Host Name . . . . . . . . . . . . : CHOADCSVR01
Primary Dns Suffix . . . . . . . : empire.corp
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : empire.corp

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : HP NC7781 Gigabit Server Adapter
Physical Address. . . . . . . . . : 00-16-35-C2-F1-A6
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 163.2.3.4
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 163.2.100.2
DNS Servers . . . . . . . . . . . : 163.2.3.4
163.2.3.1
198.235.216.130
198.235.216.131
Primary WINS Server . . . . . . . : 163.2.3.1
Secondary WINS Server . . . . . . : 163.2.3.4

Those 198.235.216.nnn DNS addresses are our ISP's DNS server, to
resolve addresses for machines not on our network (i.e. the
Internet), so our time server (DC#1) can find the time sources.

If you need anything else please let me know. Thanks.

PJ.

I apologize for the late reply and still do hope you are monitoring this
thread. I had some issues with my newsreader and just found your post as one
I was trying to help out with.

Yes, those IPs:
198.235.216.130
198.235.216.131
are what's causing the issue. Keep in mind, all AD resources are stored in
DNS. The way the DNS resolver algorithm works, when trying to enumerate or
find domain resources there may be a point in time that it is asking one of
these servers and they will not know the answer. And since it returns a
negative answer, it;'s still an answer and won't ask any of the others in
the list.

Remopve these addresses from ALL machines (if they exist anywhere else). To
achieve Internet resolution, either do nothing, the Root Hints will handle
it, or better practices is to configure a forwarder on all your DNS servers
to send any responses it is not aware of to these addresses.

I hope this helps...

Ace

 

[Microsoft Public Newsgroups]

I have removed those 198.x IP addresses and as we don't really need to do
external lookups from this box I have removed the root hints. It's still
very slow to resolve SID's to User ID's. Because this server is the
internal time server for our environment, I have a couple of NTP time
sources configured (using their IP's) and a persistent route to the Internet
help the local time service find the NTP time sources ... but that doesn't
affect DNS ... I am confident that the server isn't trying to resolve SID
queries to external DNS.

Any other ideas? Thanks.

PJ.

 

[Ace Fekay [MVP]]

In

I have removed those 198.x IP addresses and as we don't really need
to do external lookups from this box I have removed the root hints. It's
still very slow to resolve SID's to User ID's. Because this
server is the internal time server for our environment, I have a
couple of NTP time sources configured (using their IP's) and a
persistent route to the Internet help the local time service find the
NTP time sources ... but that doesn't affect DNS ... I am confident
that the server isn't trying to resolve SID queries to external DNS.

Any other ideas? Thanks.

I thought you needed to resolve external names? You can use those IPs as
forwarders. Deleting the Roots won't help in your situation either.

I'm kind of surprised that it takes that long to resolve the SIDs to a name.
Since the time you've deleted those IPs, has it improved at all? How many
levels deep are the folders you spoke of?

Are there any errors in the Event viewer? If so, can you post the Event ID#s
and Source please?

Can I assume the domain is still in mixed mode?

Ace