locked
NAP Client Reporting Non-NAP Capable RRS feed

  • Question

  • Hello,

    Windows Server 2008 running TS Gateway (NPS included), seperate Terminal Services machine.  Clients are Vista machines.  I want the client computers to connect to our VPN (not managed by us; just gives us access to through the border network security - at a university, many subnets/subdomains within the larger), then run an RDP that initiates a session with the TS Server going through the TS Gateway.

    Configured TS Gateway almost exactly out of TS Gateway Step-by-Step.  The client consistantly hits the 3rd Network Policy: NAP TS Gateway Non-NAP Capable.  TS Gateway server shows event 6272 (granted access) followed by 6227 (quarantine user).  What the heck?!  I create a simple policy, allow the selected TS user group I created, process it first, test it, no good.  Still skips down to NAP TS Gateway Non-NAP Capable.  So, one would assume that the client is not NAP Capable...

    netsh nap client show state

    Client state:
    ----------------------------------------------------
    Name                   = Network Access Protection Client
    Description            = Microsoft Network Access Protection Client
    Protocol version       = 1.0
    Status                 = Enabled
    Restriction state      = Not restricted
    Troubleshooting URL    = 
    Restriction start time = 

    Enforcement client state:
    ----------------------------------------------------
    Id                     = 79617
    Name                   = DHCP Quarantine Enforcement Client
    Description            = Provides DHCP based enforcement for NAP
    Version                = 1.0
    Vendor name            = Microsoft Corporation
    Registration date      = 
    Initialized            = No

    Id                     = 79618
    Name                   = Remote Access Quarantine Enforcement Client
    Description            = Provides the quarantine enforcement for RAS Client
    Version                = 1.0
    Vendor name            = Microsoft Corporation
    Registration date      = 
    Initialized            = No

    Id                     = 79619
    Name                   = IPSec Relying Party
    Description            = Provides IPSec based enforcement for Network Access Protection
    Version                = 1.0
    Vendor name            = Microsoft Corporation
    Registration date      = 
    Initialized            = No

    Id                     = 79621
    Name                   = TS Gateway Quarantine Enforcement Client
    Description            = Provides TS Gateway enforcement for NAP
    Version                = 1.0
    Vendor name            = Microsoft Corporation
    Registration date      = 
    Initialized            = No

    Id                     = 79623
    Name                   = EAP Quarantine Enforcement Client
    Description            = Provides EAP based enforcement for NAP
    Version                = 1.0
    Vendor name            = Microsoft Corporation
    Registration date      = 
    Initialized            = No

    System health agent (SHA) state:
    ----------------------------------------------------
    Id                     = 79744
    Name                   = Windows Security Health Agent
     
    Description            = The Windows Security Health Agent checks the compliance of a computer with an administrator-defined policy.
     
    Version                = 1.0
     
    Vendor name            = Microsoft Corporation
     
    Registration date      = 
    Initialized            = Yes
    Failure category       = None
    Remediation state      = Success
    Remediation percentage = 0
    Fixup Message          = (3237937214) - The Windows Security Health Agent has finished updating its security state.
     
    Compliance results     =
    Remediation results    =

    Ok.


    netsh nap client show group

    NAP client configuration (group policy):
    ----------------------------------------------------

    NAP client configuration:
    ----------------------------------------------------

    Cryptographic service provider (CSP) = Microsoft RSA SChannel Cryptographic Provider, keylength = 2048

    Hash algorithm = sha1RSA (1.3.14.3.2.29)

    Enforcement clients:
    ----------------------------------------------------
    Name            = DHCP Quarantine Enforcement Client
    ID              = 79617
    Admin           = Disabled

    Name            = Remote Access Quarantine Enforcement Client
    ID              = 79618
    Admin           = Disabled

    Name            = IPSec Relying Party
    ID              = 79619
    Admin           = Disabled

    Name            = TS Gateway Quarantine Enforcement Client
    ID              = 79621
    Admin           = Disabled

    Name            = EAP Quarantine Enforcement Client
    ID              = 79623
    Admin           = Disabled

    Client tracing:
    ----------------------------------------------------
    State = Disabled
    Level = Disabled

    Ok.


    I have TS Gateway Quarantine Enforcement Client enabled through Group Policy; AND, I did it locally with napclcfg.msc (GUI shows it as enabled).

    net start napagent && net stop napagent, check the Network Access Policy\Operational Event Logs
    The enforcement client 79871 successfully initialized (what the heck is this, I can find no reference to this enforcement client number, the previous event mentions NAP service starting, I assume it's that)
    The enforcement client 79744 successfully initialized (Windows Security Health Agent)
    There's a couple others about the System Health Agent detecting changes.
    No mention of any of the Enforcement Client Types.

    Security Center is Enable through Group Policy.
    Ran tsgqecclientconfig with the FQDN of the TS Gateway Server.

    I have no idea why this client is Non NAP-Capable.  Some part of Windows is lying to me, either the NAP Config GUI or netsh nap client show state...

    I referenced this thread heavily trying to troubleshoot:
    Greg and Nbctcp do 'NAP+TS Gateway error'
    • Edited by moomanX Wednesday, October 1, 2008 11:12 PM
    Wednesday, October 1, 2008 10:46 PM

Answers

  • Hi,

    Good job figuring out the GPO problem. It seems a little strange that this would be causing you to match the "non-NAP-capable" network policy though. That policy should have a condition that requires computers not send health credentials. If the computer sends credentials (statement of health), then it should either be compliant or noncompliant, not non-NAP-capable.

    Your firewall GPO issues might be caused by a conflict with profiles. Basically, you should double-check the GPO settings for the standard profile and make sure they are the same as the domain profile. When the client is disconnected from the domain it will switch to whatever settings are in the standard profile. Let me know if this helps.

    -Greg
    Tuesday, October 7, 2008 1:17 AM
  • So...
    I was on a Win2K3 box doing my Group Policy management...
    I didn't even notice the NAP settings at the bottom (the extra settings Win2K3 doesn't understand...)

    Man... man... I don't know why... or when... but, someone (probably me) put NAP settings in to our Firewall GPO; and, set everything to disabled.

    "I'm just excited to know that I'm not either a) crazy, or b) completely inept; and, something does seem to be behaving 'incorrectly'."

    I'm looking at you, B...
    Tuesday, October 7, 2008 4:37 PM

All replies

  • I got it wrong here:

    "I create a simple policy, allow the selected TS user group I created, process it first, test it, no good.  Still skips down to NAP TS Gateway Non-NAP Capable.  So, one would assume that the client is not NAP Capable..."

    I created a policy and set the Processing Order to 1, the only Condition I applied was a User Groups one; the user I'm testing with is a member of said group.  When I try to connect it results in the following event on the TS Gateway server (edited out computer/user names):
    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          10/2/2008 8:00:46 AM
    Event ID:      6273
    Task Category: Network Policy Server
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      $FQDN
    Description:
    Network Policy Server denied access to a user.

    Contact the Network Policy Server administrator for more information.

    User:
        Security ID:            NULL SID
        Account Name:            $DOMAIN\tstest
        Account Domain:            $DOMAIN
        Fully Qualified Account Name:    $FQAN/TS,Test

    Client Machine:
        Security ID:            $DOMAIN\TSCLIENT00$
        Account Name:            TSCLIENT00.$DOMAIN
        Fully Qualified Account Name:    $DOMAIN\TSCLIENT00$
        OS-Version:            -
        Called Station Identifier:        UserAuthType:PW
        Calling Station Identifier:        -

    NAS:
        NAS IPv4 Address:        -
        NAS IPv6 Address:        -
        NAS Identifier:            -
        NAS Port-Type:            Virtual
        NAS Port:            -

    RADIUS Client:
        Client Friendly Name:        -
        Client IP Address:            -

    Authentication Details:
        Proxy Policy Name:        NAP TS Gateway
        Network Policy Name:        :(
        Authentication Provider:        Windows
        Authentication Server:        $TS GATEWAY FQDN
        Authentication Type:        Unauthenticated
        EAP Type:            -
        Account Session Identifier:        -
        Reason Code:            66
        Reason:                The user attempted to use an authentication method that is not enabled on the matching network policy.

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
        <EventID>6273</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12552</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2008-10-02T14:00:46.723Z" />
        <EventRecordID>1392</EventRecordID>
        <Correlation />
        <Execution ProcessID="628" ThreadID="2608" />
        <Channel>Security</Channel>
        <Computer>$TS GATEWAY FQDN</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="SubjectUserSid">S-1-0-0</Data>
        <Data Name="SubjectUserName">$DOMAIN\tstest</Data>
        <Data Name="SubjectDomainName">$DOMAIN</Data>
        <Data Name="FullyQualifiedSubjectUserName">$FQAN/TS,Test</Data>
        <Data Name="SubjectMachineSID">S-1-5-21-4402546-48302196-1846952604-7535</Data>
        <Data Name="SubjectMachineName">TSCLIENT00.HHS.ColoState.EDU</Data>
        <Data Name="FullyQualifiedSubjectMachineName">$DOMAIN\TSCLIENT00$</Data>
        <Data Name="MachineInventory">-</Data>
        <Data Name="CalledStationID">UserAuthType:PW</Data>
        <Data Name="CallingStationID">-</Data>
        <Data Name="NASIPv4Address">-</Data>
        <Data Name="NASIPv6Address">-</Data>
        <Data Name="NASIdentifier">-</Data>
        <Data Name="NASPortType">Virtual </Data>
        <Data Name="NASPort">-</Data>
        <Data Name="ClientName">-</Data>
        <Data Name="ClientIPAddress">-</Data>
        <Data Name="ProxyPolicyName">NAP TS Gateway</Data>
        <Data Name="NetworkPolicyName">:(</Data>
        <Data Name="AuthenticationProvider">Windows </Data>
        <Data Name="AuthenticationServer">$TS GATEWAY FQDN</Data>
        <Data Name="AuthenticationType">Unauthenticated </Data>
        <Data Name="EAPType">-</Data>
        <Data Name="AccountSessionIdentifier">-</Data>
        <Data Name="ReasonCode">66</Data>
        <Data Name="Reason">The user attempted to use an authentication method that is not enabled on the matching network policy. </Data>
      </EventData>
    </Event>
    • Edited by moomanX Thursday, October 2, 2008 2:16 PM
    Thursday, October 2, 2008 2:16 PM
  • Hi,

    The netsh nap client show group command you executed shows that you actually do not have any enforcement clients enabled (via GP).

    Name            = TS Gateway Quarantine Enforcement Client
    ID              = 79621
    Admin           = Disabled

    Can you double-check that the client is recieving Group Policy settings? If you enabled it through local policy, it might work but if there are any other settings configured in Group Policy then it will ignore the local policy ones. You can perhaps try gpresult /R to troubleshoot.

    Enforcement client 79871 is the health certificate enrollment agent. It is something that works with the IPsec enforcement client and any other enforcement clients that are developed in the future that use health certificates.

    -Greg
    Thursday, October 2, 2008 10:35 PM
  • The reputable Greg responds...

    Thanks for taking a look.

    Funny thing about the whole applying these settings through Group Policy... There's not local equivalent to the NAP settings; thus, when the computer isn't connected to the domain RSOP doesn't resolve... When connected to the domain, the Group Policy Object is definitely set; and, netsh nap client show group definitely shows 79621 as Disabled.  None of this should really matter anyway (if I've read the documentation correctly); because, when the computer is turned on (prior to being connected to our VPN let alone our Domain) it should be referencing local policy.  There is no NAP local policy; thus, it should reference the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\napagent\LocalConfig\Qecs\79621 where a Binary Value called 'Enabled' is set to 1.  Yet netsh nap client show state reports Initialized = No.

    I've reinstalled Windows on the client 3 times now; each time reconfiging word for word off of the step-by-step documention.  I have a feeling I'm missing something fundamental here.  I don't understand how everything on local machine says it's enabled; but, it's like when I ask it to initialize with a network component it doesn't know what to do.
    Friday, October 3, 2008 3:15 PM
  • Hi,

    You're the second person with this problem (TS Gateway method, client showing up non-NAP capable). Unfortunately I'm not as familiar with the TS Gateway method as other enforcement methods, and I didn't write the TS Gateway step by step guide as I did with the other guides. The basic principals should be the same, however. There are three things that cause a client to be evaluated as non-NAP-capable:

    1) NAP agent service not running.
    2) Enforcement client disabled.
    3) "Quarantine" checks not enabled.

    The third item only applies for EAP-based enforcement methods such as VPN and 802.1X. In your setup, it looks like the second item is what is causing the problem.

    Looking at the TS Gateway step by step guide, a script is used to enable the enforcement client. I looked at the script and this is enabling via local policy and not GP, so we should focus on that. One thing to remember about local and GP settings is that if you have any setting in GP then the client will ignore local settings. This occurs even when the client is currently disconnected from the domain. So, if you domain joined the client and applied some NAP client settings, then disconnected the client from the domain, the local settings will have no effect.

    Looking at your Group Policy settings for NAP, I don't see anything here so this might not be interfering with the local settings. Sorry I didn't see before that all the instructions are for local settings, not GP.

    Here are the settings that the script pushes:

    echo Setting the list of trusted TS Gateway servers to %1 ...
    reg add "HKLM\Software\Microsoft\Terminal Server Client\TrustedGateways" /v GatewayFQDN /t REG_MULTI_SZ /d %1 /f

    echo Enabling the TS Gateway Quarantine Enforcement Client
    reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\napagent\LocalConfig\Qecs\79621 /v Enabled /t REG_DWORD /d 1 /f

    echo Setting the Network Access Protection service startup type to Automatic...
    sc config napagent start= auto

    echo Starting the Network Access Protection service...
    net start napagent

    I don't know if you ran this script or set it up manually, but either method should work.

    I see the NAP agent is running from the output you provided from netsh nap client show state. Please provide the results of netsh nap client show config which will show the local settings. From what you've said about the registry key and from the issues in the other post, I am guessing that you do have the enforcement client enabled and it just isn't initializing. This might be similar to the VPN enforcement client, which doesn't automatically initialize until you make a connection.

    I'll spend some time reviewing the TS Gateway step by step in detail and if I don't see anything that would be likely to causes this problem I'll set the scenario up myself this weekend.
     
    -Greg
    Friday, October 3, 2008 3:56 PM
  • "One thing to remember about local and GP settings is that if you have any setting in GP then the client will ignore local settings. This occurs even when the client is currently disconnected from the domain. So, if you domain joined the client and applied some NAP client settings, then disconnected the client from the domain, the local settings will have no effect."

    I was not fully aware of that (in fact I had it backwards in my head), thank you for making the distinction.

    netsh nap client show config:
    NAP client configuration:
    ----------------------------------------------------

    Cryptographic service provider (CSP) = Microsoft RSA SChannel Cryptographic Provider, keylength = 2048

    Hash algorithm = sha1RSA (1.3.14.3.2.29)

    Enforcement clients:
    ----------------------------------------------------
    Name            = DHCP Quarantine Enforcement Client
    ID              = 79617
    Admin           = Disabled

    Name            = Remote Access Quarantine Enforcement Client
    ID              = 79618
    Admin           = Disabled

    Name            = IPSec Relying Party
    ID              = 79619
    Admin           = Disabled

    Name            = TS Gateway Quarantine Enforcement Client
    ID              = 79621
    Admin           = Enabled

    Name            = EAP Quarantine Enforcement Client
    ID              = 79623
    Admin           = Disabled

    Client tracing:
    ----------------------------------------------------
    State = Disabled
    Level = Disabled

    Ok.

    So, yeah, it looks like you are correct (which isn't really surprising - I've read through quite a few of the threads here, and you happen to do that a lot).
    Now I just need to figure out how to ask Windows nicely enough, to get it initialized...
    Friday, October 3, 2008 4:38 PM
  • Hi,

    I see what might be a mistake in the TS Gateway step by step guide. I think a step is missing.

    On your NPS server, go to the RADIUS Clients and Servers\RADIUS clients and double-click the TS Gateway server. On the bottom of this properties page, place a check in the box that says "RADIUS client is NAP-capable."

    Let me know if this fixes the problem.

    Thanks,
    -Greg

    Friday, October 3, 2008 4:38 PM
  • RADIUS Clients was empty.
    I created a New RADIUS Client...
    Friendly Name and Address, I plugged in the FQDN
    Vendor: RADIUS Standard
    Shared Secret: Manual (empty)
    Additional Options: RADIUS client is NAP-capable

    Still didn't get processed until it hit Non NAP-Capable, that's unfortunate.
    Friday, October 3, 2008 4:48 PM
  • OK the step by step guide isn't too clear on this, but the NAP configuration wizard tells the story correctly. If the TS Gateway server is on a separate machine from NPS, you need to configure a RADIUS client. If NPS and TS Gateway are on the same machine, you don't need this. You said in your first post that you have them on separate machines, so you do need to configure the RADIUS client.

    Unfortunately, the step by step guide doesn't use TS Gateway and NPS on separate machines, it has them both on the same machine (In this scenario, TSGSERVER is used as the TS Gateway server and as an NPS server...) - even though the diagram shows them on different machines. Both scenarios are valid, but obviously the configuration will differ slightly.

    The step I mentioned (configuring the RADIUS client as NAP-capable) is required as confirmed in the blog post at http://blogs.technet.com/nap/archive/2008/08/15/the-radius-client-is-nap-capable-check-box.aspx.

    What I'm trying to establish now is how the TS Gateway server uses RADIUS to authenticate. If you are familiar with TS Gateway you might know this better than me. There are two possibilities. If TS Gateway has a built-in RADIUS client (like RRAS does) then you don't need to install NPS on the TS Gateway machine to forward authentication requests to NPS. If TS Gateway doesn't have this, then you need to install NPS and configure it as a proxy similar to what is done with the DHCP and IPsec NAP scenarios. I *think* that TS Gateway has a built in RADIUS client similar to RRAS based on some reading I've done.

    Let's make sure that the communication between NPS and the TS Gateway is working as expected.

    Open the TS Gateway Manager Console, right-click on the server's name, and choose the option Properties. On the server's properties window, click on the TS CAP Store tab and select the NPS server. Next, type the name or IP address of the NPS server and click on the Add button. You'll see a Shared Secret window pop up. Type the secret and click OK, then click OK again to close the window. Now open the RADIUS client list on NPS that was configured with the TS Gateway server and type in the same shared secret.

    Again, let me know if this helps.
    -Greg
    Friday, October 3, 2008 5:35 PM
  • From my first post:
    "TS Gateway (NPS included), seperate Terminal Services machine"

    NPS and TS Gateway are the same machine; it's actually the Terminal Server that's the separate machine; sorry I mislead you!
    • Edited by moomanX Friday, October 3, 2008 5:42 PM
    Friday, October 3, 2008 5:41 PM
  • Ahh, thanks for clarifying that.

    There does seem to be disagreement between the NAP wizard and the step by step guide.

    See step 5 on http://technet.microsoft.com/en-us/library/cc732172.aspx

    5. On the Specify NAP Enforcement Servers Running TS Gateway page, under TS Gateway servers, confirm that TS Gateway server is specified, and then click Next.

    However, the wizard says "If TS Gateway is running only on the local computer, click Next."

    I tend to think that the wizard is right and the guide is wrong here because you have been getting client authentication requests already without having added a RADIUS client. So, I think you can go ahead and delete the RADIUS client we created.

    Unfortunately, that leaves us back one square one - not knowing why the enforcement client is not initializing. I think I am going to have to configure this scenario myself and test it. Sorry for the delay.

    -Greg

    Friday, October 3, 2008 6:02 PM
  • Oh, that's interesting.  I am familiar with that step in the wizard; and, I did leave it 'blank' and just clicked Next.

    No need to be sorry for the delay!  I'm just excited to know that I'm not either a) crazy, or b) completely inept; and, something does seem to be behaving 'incorrectly'.

    I'll look in to wiping out my policy and running the wizard again specifying the server on that step...
    Friday, October 3, 2008 6:13 PM
  • So, I disabled all my current Network Policies, Connection Authorization Policies, and the one Connection Request Policy that applied.  I left Resource Authorization Policy and Health Policies alone; although, new Health Policies were created in the next process.  I ran the 'Configure NAP' wizard again; and, this time I picked the TS Gateway Server (that I had just created this morning - I haven't deleted it yet).  New Network Policies, etc were created.

    Unfortunately, the same behavior persisted.  After attempting to connect the client, I got quarantined by the Non NAP-Capable policy.

    Gonna keep tweaking and testing...
    • Edited by moomanX Friday, October 3, 2008 8:12 PM that last sentence read really funny.
    Friday, October 3, 2008 8:10 PM
  • Holy ____...

    HOLY ____... HOW MANY TIMES WINDOWS?! HOW MANY!?!

    Looks like I was foiled by the Windows Firewall once again.  The one on the client machine; that is.  I disabled the firewall and the firewall Security Health Validator:

    Network Policy Server granted full access to a user because the host met the defined health policy...
    Network Policy Name:        NAP TS Gateway Compliant

    Need to work this out completely before I'm satisfied, though.

    edit- so, the question is; what exception do I have to configure to make the local firewall happy...
    • Edited by moomanX Monday, October 6, 2008 3:56 PM
    Monday, October 6, 2008 3:21 PM
  • Alright,

    This confuses me so much, so much.

    We have a Group Policy Object that contains rules for the Windows Firewall on clients.  Said policy makes it impossible to change firewall settings locally.

    So, I turned disabled the 'Link Enabled' on that GPO for this computer group.
    Boot it up on the network so Group Policy gets updated.  Disconnect it from the network.  Log on as a local admin; and I completely disable Windows Firewall.

    I attempt to connect (through a wireless network connection, and our VPN) to the TS Gateway, denied because I don't meet specified health policy!
    ALRIGHT!
    So, I disable the Firewall Health Validator; attempt to connect again, SUCCESS!

    This is where I get confused:
    I make two exceptions on the local firewall, TCP 80 and TCP 443.  Flip the firewall back on.  Attempt connection; success.
    Disable TCP 80; success.
    Disable TCP 443; success... ?!  Wait, what?  You're really going to work even though I just disabled the exception(s) that you just needed?

    Alright, fine.  I start to think it's got to be something in the firewall GPO that's causing the malfunction.
    Re-enable that GPO, reboot the machine, log on to our network; reboot the machine and log on locally...

    Wow.  It's the GPO... ...
    ARG!  Spent a week barking up the wrong tree.  I don't know how that GPO is even blocking outbout 443's, sheesh.

    Anyway.
    Greg, THANKS!  Very prompt and helpful!  Tell your boss you deserve a raise!

    edit- yeah, I have no idea what this pos Window's firewall is doing with group policy.  I can make the Group Policy object allow everything through the firewall; and it doesn't work.  But, if I disable the GPO (all policy still applied from the last time the client hit Group Policy) and everything works - all the same allows and exceptions, just can manage the firewall locally.

    That's just stupid.  Or, I am.  One of the two.
    • Edited by moomanX Monday, October 6, 2008 6:23 PM
    Monday, October 6, 2008 4:37 PM
  • Hi,

    Good job figuring out the GPO problem. It seems a little strange that this would be causing you to match the "non-NAP-capable" network policy though. That policy should have a condition that requires computers not send health credentials. If the computer sends credentials (statement of health), then it should either be compliant or noncompliant, not non-NAP-capable.

    Your firewall GPO issues might be caused by a conflict with profiles. Basically, you should double-check the GPO settings for the standard profile and make sure they are the same as the domain profile. When the client is disconnected from the domain it will switch to whatever settings are in the standard profile. Let me know if this helps.

    -Greg
    Tuesday, October 7, 2008 1:17 AM
  • So...
    I was on a Win2K3 box doing my Group Policy management...
    I didn't even notice the NAP settings at the bottom (the extra settings Win2K3 doesn't understand...)

    Man... man... I don't know why... or when... but, someone (probably me) put NAP settings in to our Firewall GPO; and, set everything to disabled.

    "I'm just excited to know that I'm not either a) crazy, or b) completely inept; and, something does seem to be behaving 'incorrectly'."

    I'm looking at you, B...
    Tuesday, October 7, 2008 4:37 PM
  •  LOL!

    I've been mystified by client behavior on more than one occasion because somehow I configured the wrong GPO. At least your troubleshooting pointed to the problem =) Congrat on solving it!

    -Greg 

    Tuesday, October 7, 2008 10:47 PM