DisableStrictNameChecking and Application Managment

  • Thread starter Thread starter Rory Plaire
  • Start date Start date
R

Rory Plaire

Hi,

I posted this message to the AD group a couple of months ago, and got
no response. Perhaps this is a more fertile ground. Thanks! -rory 8)
----------------------------------------

Greetings,

I have been using DNS aliases to refer to servers and shares, e.g.
\\apps\installs refers to \\mysrv123\installs. I followed the
information in KB article
http://support.microsoft.com/default.aspx?scid=kb;en-us;281308 which
works well... except, apparently, for group policy application
manangment.

A google groups article mentioned this about 18 months ago:
http://groups.google.com/groups?hl=...llation&num=50&hl=en&lr=&ie=UTF-8&sa=N&tab=wg
( http://makeashorterlink.com/?T20832029 )

However, it doesn't look like any resolution was offered. Why does app
managment break when using DNS aliases for CIFS shares?

thanks!
-rory
 
I suggest you run network monitor to capture the traffic from the client.
This will help narrow down what is failing.
You can also turn up diagnostic logging on applicaiton management. Though
if the error is 'source files not available' then the diagnostic logging
will be of little use.
It sounds like the same failure as what you would get if you did not apply
the fix and the registry key.
I seem to recall there was a way to specify what host names a server would
respond to in addition to the disablestrictnamechecking registry key.
I could not find any reference to that at the moment though.

You may need to call PSS on this one.
Get a network trace first.
I'd be happy to look at it.
 
Glenn L said:
I suggest you run network monitor to capture the traffic from the client.
This will help narrow down what is failing.

This sounds like good advice. I'll do it. You're right about verbose
logging not giving anything other than "source files not available."

I'll post the logs when I get them.

thanks,
-rory
 
Hi Glenn,

I think I found the reason for this problem... the SYSTEM account,
under which app managment runs, generates an access denied error when
accessing CNAME'd network shares. I think this is an implementation
problem. It would be nice if Microsoft supported this "feature" (er,
hack) better.

-rory
 
Hello,

I have come across the exact same issue, is there any update to this thread or does anyone know of a fix for it?
 
Back
Top