checking for / accessing custom attribute fails with 0x800..

Toggle sidebar Toggle sidebar
J

Jabba

Distinguished
May 1, 2004
20
0
18,510
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

Hi guys,
I have created a custom attribute called tst-PwdDomainPolicy (unicode,
multivalued) on our win2000 AD server using a SchemaAdmin account and the
Schema editor snap-in. A dummy X500 identifier was used. It was replicated
on the other AD server correctly. I then asigned the attribute to the
OrganizationalUnit (OU) class.

I can see and edit this attribute for any given OU from a client machine
being logged in with a domain administrator account, using ADSIEdit. The
reason I insist on the security context in which the tools are ran will
become obvious later on.

I am now trying to get the values of the said custom attribute from a given
user name and OU that the user is part of in .NET app running under the
domain admin account. Rememeber, the attribute is part of the OU class.

I cannot get it.


Here 's the relevant code:

Code: 
  try {
    DirectoryEntry de = null;
    string userPath = string.Format("LDAP://cn={0},ou={1},{2}", 
name.ToUpper(), ou.ToUpper(), permsLDAPSuffix);
    de = new DirectoryEntry(userPath);
    RefreshCache(de);
    StringCollection scPwdPolicy =null;
    DirectoryEntry deParent = de.Parent;//this is the OU I am after
    RefreshCache(deParent);
    scPwdPolicy=getDomainPwdPolicy(deParent);
    return new User(de, this,scPwdPolicy);//whatever...
   } catch (System.Runtime.InteropServices.COMException)

the getDomainPwdPolicy looks like this:

Code: 
  private StringCollection getDomainPwdPolicy(DirectoryEntry de)
  {
   try
   {

    //testcode
    intConfig.Log.Log(Severity.Trace, "The following properties are 
supported by the {0} organizational unit ", de.Name);
    foreach(string key in de.Properties.PropertyNames)
    {
     intConfig.Log.Log(Severity.Trace, "{0}", key );
    }

   //end testcode


    if(de.Properties.Contains("tst-PwdDomainPolicy"))
    {

     PropertyValueCollection pvc = de.Properties["tst-PwdDomainPolicy"];
     if((pvc!=null)&&(pvc.Count!=0))
     {
      StringCollection sc = new 
System.Collections.Specialized.StringCollection();
      foreach (string p in pvc)
      {
       sc.Add(p);
      }
      return sc;
     }
    }
   }
   catch (System.Runtime.InteropServices.COMException e)
   {
    intConfig.Log.Log(Severity.Critical, "Caught COMException while trying 
to retrieve the OU password policy : #{0:x}, {1}", e.ErrorCode, e.Message);
   }
   return null;

the output for this is :

TRACE-08/29/2005 09:35:58.326-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-The following properties are
supported by the ou=PLAYGROUND organizational unit
TRACE-08/29/2005 09:35:58.627-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-dSCorePropagationData
TRACE-08/29/2005 09:35:58.627-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-instanceType
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-nTSecurityDescriptor
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-distinguishedName
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-objectCategory
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-objectClass
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-objectGUID
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-ou
TRACE-08/29/2005 09:35:58.877-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-name
TRACE-08/29/2005 09:35:58.887-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-uSNChanged
TRACE-08/29/2005 09:35:58.887-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-uSNCreated
TRACE-08/29/2005 09:35:58.887-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-whenChanged
TRACE-08/29/2005 09:35:58.887-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-whenCreated
TRACE-08/29/2005 09:35:58.887-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-tst-PwdDomainPolicy

CRITICAL-08/29/2005 09:35:58.937-[3144
(UserStoreImpl.exe)/UserStoreImpl/d5c]-Caught COMException while trying to
retrieve the OU password policy : #8000500c, The directory datatype cannot
be converted to/from a native DS datatype

In case you wonder, the line that throws the exception is :

Code: 
   if(de.Properties.Contains("tst-PwdDomainPolicy"))
    {

which is at least weird. Especially since the propertly is listed as
available by the enumeration just before the faulty code line.


Now some side notes: I am well aware of the schema cache refresh issue
described here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;241981

That's why I use the RefreshCache(...) call:

public static void RefreshCache(DirectoryEntry entry)
{
try
{
if(entry != null)
{
if(entry.SchemaEntry != null)
entry.SchemaEntry.RefreshCache(); //force refresh of schema
entry.RefreshCache(); //force reload of cache info
}
}
catch (Exception e)
{
intConfig.Log.Log(Severity.Critical,"Exception in
DirectoryEntry:{0}{1}SchemaEntry:
{2}",entry.Path,entry.SchemaEntry.Path,e.Message);
}
}
This never throws, BTW. Which probably means the the domain admin guy
(who's running this) can access the schema.


Besides, both the server and the client machines have been restarted since
the schema change so the cache is probably in the right stage, as proven by
the TRACE messages above

Based on my research , I beleieve that there might be an issue with the
*attribute ownership* in that the attribute is owned by the schema admin guy
and the domain admin guy cannot access it (although this doesn't explain why
I can edit it with ADSI edit running under the domain admin guy's login). So
I am trying to change the ownership of the attribute . But AD GUI tools
don't list the ownership lists by default. It is hidden. To enable AD to use
List Object permission, one must modify cn=Directory Service,cn=Windows
NT,cn=Services,cn=Configuration,dc=subdomain,dc=domain,dc=com. The
dSHeuristics attribute should have a value "001" to enable this permission.
And here is where I had to stop. No matter how powerful a user I am using
(Administrators included ) the ADSI edit says I don't have enough rights to
change this attribute.

Please advise, either with the original issue, either with the secondary
one.



Thanks,

Jabba
 
G

Guest

Guest
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

This is most likely a schema cache problem, but RefreshCache does not fix
them.

My guess is that you need to clear the cached schema on the file system in
the app to make sure you are getting a fresh copy of the local schema on the
machine. It is stored in the <windows dir>\SchCache folder. If those files
are dated earlier than your last applied schema mod, then that is likely the
problem.

ADSI is supposed to update those for you, but it might be the case that the
code that is running the ADSI code does not have the permissions to update
the files or registry keys associated with the cached schema.

Joe K.

"Jabba" <mcjabba@iname.com> wrote in message
news:eitujENrFHA.1252@TK2MSFTNGP09.phx.gbl...
> Hi guys,
> I have created a custom attribute called tst-PwdDomainPolicy (unicode,
> multivalued) on our win2000 AD server using a SchemaAdmin account and the
> Schema editor snap-in. A dummy X500 identifier was used. It was replicated
> on the other AD server correctly. I then asigned the attribute to the
> OrganizationalUnit (OU) class.
>
> I can see and edit this attribute for any given OU from a client machine
> being logged in with a domain administrator account, using ADSIEdit. The
> reason I insist on the security context in which the tools are ran will
> become obvious later on.
>
> I am now trying to get the values of the said custom attribute from a
> given user name and OU that the user is part of in .NET app running under
> the domain admin account. Rememeber, the attribute is part of the OU
> class.
>
> I cannot get it.
>
>
> Here 's the relevant code:
>
>
Code: 
>  try {
>    DirectoryEntry de = null;
>    string userPath = string.Format("LDAP://cn={0},ou={1},{2}", 
> name.ToUpper(), ou.ToUpper(), permsLDAPSuffix);
>    de = new DirectoryEntry(userPath);
>    RefreshCache(de);
>    StringCollection scPwdPolicy =null;
>    DirectoryEntry deParent = de.Parent;//this is the OU I am after
>    RefreshCache(deParent);
>    scPwdPolicy=getDomainPwdPolicy(deParent);
>    return new User(de, this,scPwdPolicy);//whatever...
>   } catch (System.Runtime.InteropServices.COMException)
>
>
> the getDomainPwdPolicy looks like this:
>
>
Code: 
>  private StringCollection getDomainPwdPolicy(DirectoryEntry de)
>  {
>   try
>   {
>
>    //testcode
>    intConfig.Log.Log(Severity.Trace, "The following properties are 
> supported by the {0} organizational unit ", de.Name);
>    foreach(string key in de.Properties.PropertyNames)
>    {
>     intConfig.Log.Log(Severity.Trace, "{0}", key );
>    }
>
>   //end testcode
>
>
>    if(de.Properties.Contains("tst-PwdDomainPolicy"))
>    {
>
>     PropertyValueCollection pvc = de.Properties["tst-PwdDomainPolicy"];
>     if((pvc!=null)&&(pvc.Count!=0))
>     {
>      StringCollection sc = new 
> System.Collections.Specialized.StringCollection();
>      foreach (string p in pvc)
>      {
>       sc.Add(p);
>      }
>      return sc;
>     }
>    }
>   }
>   catch (System.Runtime.InteropServices.COMException e)
>   {
>    intConfig.Log.Log(Severity.Critical, "Caught COMException while trying 
> to retrieve the OU password policy : #{0:x}, {1}", e.ErrorCode, 
> e.Message);
>   }
>   return null;
>
>
>
> the output for this is :
>
> TRACE-08/29/2005 09:35:58.326-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-The following properties are
> supported by the ou=PLAYGROUND organizational unit
> TRACE-08/29/2005 09:35:58.627-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-dSCorePropagationData
> TRACE-08/29/2005 09:35:58.627-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-instanceType
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-nTSecurityDescriptor
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-distinguishedName
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-objectCategory
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-objectClass
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-objectGUID
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-ou
> TRACE-08/29/2005 09:35:58.877-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-name
> TRACE-08/29/2005 09:35:58.887-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-uSNChanged
> TRACE-08/29/2005 09:35:58.887-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-uSNCreated
> TRACE-08/29/2005 09:35:58.887-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-whenChanged
> TRACE-08/29/2005 09:35:58.887-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-whenCreated
> TRACE-08/29/2005 09:35:58.887-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-tst-PwdDomainPolicy
>
> CRITICAL-08/29/2005 09:35:58.937-[3144
> (UserStoreImpl.exe)/UserStoreImpl/d5c]-Caught COMException while trying to
> retrieve the OU password policy : #8000500c, The directory datatype cannot
> be converted to/from a native DS datatype
>
> In case you wonder, the line that throws the exception is :
>
>
Code: 
>   if(de.Properties.Contains("tst-PwdDomainPolicy"))
>    {
>
>
> which is at least weird. Especially since the propertly is listed as
> available by the enumeration just before the faulty code line.
>
>
> Now some side notes: I am well aware of the schema cache refresh issue
> described here:
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;241981
>
> That's why I use the RefreshCache(...) call:
>
> public static void RefreshCache(DirectoryEntry entry)
> {
> try
> {
> if(entry != null)
> {
> if(entry.SchemaEntry != null)
> entry.SchemaEntry.RefreshCache(); //force refresh of schema
> entry.RefreshCache(); //force reload of cache info
> }
> }
> catch (Exception e)
> {
> intConfig.Log.Log(Severity.Critical,"Exception in
> DirectoryEntry:{0}{1}SchemaEntry:
> {2}",entry.Path,entry.SchemaEntry.Path,e.Message);
> }
> }
> This never throws, BTW. Which probably means the the domain admin guy
> (who's running this) can access the schema.
>
>
> Besides, both the server and the client machines have been restarted
> since the schema change so the cache is probably in the right stage, as
> proven by the TRACE messages above
>
> Based on my research , I beleieve that there might be an issue with the
> *attribute ownership* in that the attribute is owned by the schema admin
> guy and the domain admin guy cannot access it (although this doesn't
> explain why I can edit it with ADSI edit running under the domain admin
> guy's login). So I am trying to change the ownership of the attribute .
> But AD GUI tools don't list the ownership lists by default. It is hidden.
> To enable AD to use List Object permission, one must modify cn=Directory
> Service,cn=Windows
> NT,cn=Services,cn=Configuration,dc=subdomain,dc=domain,dc=com. The
> dSHeuristics attribute should have a value "001" to enable this
> permission. And here is where I had to stop. No matter how powerful a user
> I am using (Administrators included ) the ADSI edit says I don't have
> enough rights to change this attribute.
>
> Please advise, either with the original issue, either with the secondary
> one.
>
>
>
> Thanks,
>
> Jabba
>
>
 
J

Jabba

Distinguished
May 1, 2004
20
0
18,510
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

Nice tip, tried it, still got the same behaviour...I am watching the schema
with notepad and it the custom attribute *is* present and it is asigned to
the OU class.
Thanks anyway.

Jabba



Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote in
message news:%23thsJ7NrFHA.3016@TK2MSFTNGP12.phx.gbl...
> This is most likely a schema cache problem, but RefreshCache does not fix
> them.
>
> My guess is that you need to clear the cached schema on the file system in
> the app to make sure you are getting a fresh copy of the local schema on
> the machine. It is stored in the <windows dir>\SchCache folder. If those
> files are dated earlier than your last applied schema mod, then that is
> likely the problem.
>
> ADSI is supposed to update those for you, but it might be the case that
> the code that is running the ADSI code does not have the permissions to
> update the files or registry keys associated with the cached schema.
>
> Joe K.
>
> "Jabba" <mcjabba@iname.com> wrote in message
> news:eitujENrFHA.1252@TK2MSFTNGP09.phx.gbl...
[snip...]
 
G

Guest

Guest
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

Weird. I'm not sure if I know what the error is then. There isn't any
tracing available for the schema mapping stuff that ADSI does, so it can be
hard to decipher.

Have you tried playing with it using ldp.exe? It bypasses ADSI, so there is
no schema mapping. It is my favorite DS programming tool.

You might also try the trick of casting the NativeObject to an
IADsPropertyList and use the IADsPropertyValue stuff to get the value (check
the docs). However, that should not be needed.

Joe K.

"Jabba" <mcjabba@iname.com> wrote in message
news:edbLHcXrFHA.1256@TK2MSFTNGP09.phx.gbl...
> Nice tip, tried it, still got the same behaviour...I am watching the
> schema with notepad and it the custom attribute *is* present and it is
> asigned to the OU class.
> Thanks anyway.
>
> Jabba
>
>
>
> Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> in message news:%23thsJ7NrFHA.3016@TK2MSFTNGP12.phx.gbl...
>> This is most likely a schema cache problem, but RefreshCache does not fix
>> them.
>>
>> My guess is that you need to clear the cached schema on the file system
>> in the app to make sure you are getting a fresh copy of the local schema
>> on the machine. It is stored in the <windows dir>\SchCache folder. If
>> those files are dated earlier than your last applied schema mod, then
>> that is likely the problem.
>>
>> ADSI is supposed to update those for you, but it might be the case that
>> the code that is running the ADSI code does not have the permissions to
>> update the files or registry keys associated with the cached schema.
>>
>> Joe K.
>>
>> "Jabba" <mcjabba@iname.com> wrote in message
>> news:eitujENrFHA.1252@TK2MSFTNGP09.phx.gbl...
> [snip...]
>
 
J

Jabba

Distinguished
May 1, 2004
20
0
18,510
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

For the benefit of the others who might follow:
- it was not this :
http://support.microsoft.com/default.aspx?scid=kb;en-us;241981
- neither this :
http://support.microsoft.com/default.aspx?scid=KB;EN-US;888243

A MS guy figured out for me. Thanks, you know who you are :))

If one wants to access a custom attribute from a machine that is not part of
the domain where the custom attribute resides (the credentials of the logged
in user don't matter) one needs to pass the fully qualified name of the
object is trying to access otherwise the schema cache on the client machine
is not properly refreshed, nevermind all the schema.refresh() calls you make
:

e.g in my case LDAP://companydev.com/OU= permissions, DC= companydev, DC=
com is needed to properly get the DirectoryServices.DirectoryEntry or the
ActiveDs.IADsOU for the object

instead of simply LDAP://OU= permissions, DC= companydev, DC= com



Note that you *don*t* have to pass the full controller name as in

LDAP://dev20.companydev.com/OU= permissions, DC= companydev, DC= com

Jabba

"Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
in message news:OtYGatfrFHA.2596@TK2MSFTNGP09.phx.gbl...
> Weird. I'm not sure if I know what the error is then. There isn't any
> tracing available for the schema mapping stuff that ADSI does, so it can
> be hard to decipher.
>
> Have you tried playing with it using ldp.exe? It bypasses ADSI, so there
> is no schema mapping. It is my favorite DS programming tool.
>
> You might also try the trick of casting the NativeObject to an
> IADsPropertyList and use the IADsPropertyValue stuff to get the value
> (check the docs). However, that should not be needed.
>
> Joe K.
>
> "Jabba" <mcjabba@iname.com> wrote in message
> news:edbLHcXrFHA.1256@TK2MSFTNGP09.phx.gbl...
>> Nice tip, tried it, still got the same behaviour...I am watching the
>> schema with notepad and it the custom attribute *is* present and it is
>> asigned to the OU class.
>> Thanks anyway.
>>
>> Jabba
>>
>>
>>
>> Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
>> in message news:%23thsJ7NrFHA.3016@TK2MSFTNGP12.phx.gbl...
>>> This is most likely a schema cache problem, but RefreshCache does not
>>> fix them.
>>>
>>> My guess is that you need to clear the cached schema on the file system
>>> in the app to make sure you are getting a fresh copy of the local schema
>>> on the machine. It is stored in the <windows dir>\SchCache folder. If
>>> those files are dated earlier than your last applied schema mod, then
>>> that is likely the problem.
>>>
>>> ADSI is supposed to update those for you, but it might be the case that
>>> the code that is running the ADSI code does not have the permissions to
>>> update the files or registry keys associated with the cached schema.
>>>
>>> Joe K.
>>>
>>> "Jabba" <mcjabba@iname.com> wrote in message
>>> news:eitujENrFHA.1252@TK2MSFTNGP09.phx.gbl...
>> [snip...]
>>
>
>
 
G

Guest

Guest
Archived from groups: microsoft.public.active.directory.interfaces,microsoft.public.adsi.general,microsoft.public.win2000.active_directory (More info?)

God I hate ADSI. You don't have any of those issues in the LDAP API.



--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net


Jabba wrote:
> For the benefit of the others who might follow:
> - it was not this :
> http://support.microsoft.com/default.aspx?scid=kb;en-us;241981
> - neither this :
> http://support.microsoft.com/default.aspx?scid=KB;EN-US;888243
>
> A MS guy figured out for me. Thanks, you know who you are :))
>
> If one wants to access a custom attribute from a machine that is not part of
> the domain where the custom attribute resides (the credentials of the logged
> in user don't matter) one needs to pass the fully qualified name of the
> object is trying to access otherwise the schema cache on the client machine
> is not properly refreshed, nevermind all the schema.refresh() calls you make
> :
>
> e.g in my case LDAP://companydev.com/OU= permissions, DC= companydev, DC=
> com is needed to properly get the DirectoryServices.DirectoryEntry or the
> ActiveDs.IADsOU for the object
>
> instead of simply LDAP://OU= permissions, DC= companydev, DC= com
>
>
>
> Note that you *don*t* have to pass the full controller name as in
>
> LDAP://dev20.companydev.com/OU= permissions, DC= companydev, DC= com
>
> Jabba
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
> in message news:OtYGatfrFHA.2596@TK2MSFTNGP09.phx.gbl...
>
>>Weird. I'm not sure if I know what the error is then. There isn't any
>>tracing available for the schema mapping stuff that ADSI does, so it can
>>be hard to decipher.
>>
>>Have you tried playing with it using ldp.exe? It bypasses ADSI, so there
>>is no schema mapping. It is my favorite DS programming tool.
>>
>>You might also try the trick of casting the NativeObject to an
>>IADsPropertyList and use the IADsPropertyValue stuff to get the value
>>(check the docs). However, that should not be needed.
>>
>>Joe K.
>>
>>"Jabba" <mcjabba@iname.com> wrote in message
>>news:edbLHcXrFHA.1256@TK2MSFTNGP09.phx.gbl...
>>
>>>Nice tip, tried it, still got the same behaviour...I am watching the
>>>schema with notepad and it the custom attribute *is* present and it is
>>>asigned to the OU class.
>>> Thanks anyway.
>>>
>>>Jabba
>>>
>>>
>>>
>>>Joe Kaplan (MVP - ADSI)" <joseph.e.kaplan@removethis.accenture.com> wrote
>>>in message news:%23thsJ7NrFHA.3016@TK2MSFTNGP12.phx.gbl...
>>>
>>>>This is most likely a schema cache problem, but RefreshCache does not
>>>>fix them.
>>>>
>>>>My guess is that you need to clear the cached schema on the file system
>>>>in the app to make sure you are getting a fresh copy of the local schema
>>>>on the machine. It is stored in the <windows dir>\SchCache folder. If
>>>>those files are dated earlier than your last applied schema mod, then
>>>>that is likely the problem.
>>>>
>>>>ADSI is supposed to update those for you, but it might be the case that
>>>>the code that is running the ADSI code does not have the permissions to
>>>>update the files or registry keys associated with the cached schema.
>>>>
>>>>Joe K.
>>>>
>>>>"Jabba" <mcjabba@iname.com> wrote in message
>>>>news:eitujENrFHA.1252@TK2MSFTNGP09.phx.gbl...
>>>
>>>[snip...]
>>>
>>
>>
>
>
 
You must log in or register to reply here.

TRENDING THREADS

Latest posts

Moderators online

Share this page

COMPANY
RESOURCES
FOLLOW
Top Bottom