Re: Wireless connection problem from XP Pro SP2 to SBS 2003

I'm not sure to make of that "unable to download" thing. It's strange given that the other certs seem to be working. As long as you're sure the certificate is properly installed on the PC, I guess the priority would be to get wireless working, then worry about the auto enrollment later.

I wonder if it's a problem with this specific certificate. In that case, you could create another certificate and hope to get that one to auto enroll. Again without knowing the original configuration, it's difficult to tell where to make the setting for which certificate to use. It's generally in a GPO under Computer -> Windows -> Security -> Wireless Network (IEEE 802.11) Policies.



"Cuervolush" <Cuervolush@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:78DDDE3D-0D04-4C27-9A8E-0AD25E2BA3A6@xxxxxxxxxxxxxxxx
Thanks for the ideas Dave, I've got to run service calls today but when I get
back I'll check the things you've mentioned. Also I wanted to add this info
that I found yesterday. I think I've found the problem with the
autoenrollment.

After doing some research I've run across the PKIView utility. When I run
this on the SBS server, I have 2 entries that show "unable to download". I
took a print screen and uploaded it to my ftp
(http://www.cuervolush.com/work/pkiview.rtf) if you need to see the
screenshot. I suspect this is likely the cause of my problems, although I'm
unsure of how to fix this and I don't want to cause any problems with the
working PCs.



"Dave Nickason [SBS MVP]" wrote:

You weren't the one who originally configured this wireless, right? I would
compare all the settings between the non-working PC and the one that works.
It would be helpful to know how the original configuration was applied. If
it was group policy, you can run RSOP.msc on both the working and
non-working machines, and compare the settings under Computer
Configuration -> Windows Settings -> Security Settings - check the Wireless
Network and Public Key policies. Either in group policy, or manually
configured settings, just make sure that everything matches between the two
machines. (Of course the group policies would match between the machines,
unless the problem machine is not applying the policy for some reason).

What's doing the authentication? IAS? If so, open Internet Authentication
Service on the SBS. R-click the top item in the left pane -> Properties.
Turn on logging for success and failure. Try to log in, and see if IAS logs
anything. (You'll want to turn success logging off after diagnosing this to
avoid overwhelming your system log).

Assuming all the settings are the same, and also assuming IAS isn't logging
anything, you can pretty well blame hardware for this. It could be the
wireless NIC driver, or the wireless NIC itself. The one time I had a
wireless NIC fail, it would authenticate successfully maybe one time in a
hundred - intermittent wireless failures are just about always hardware
related (including drivers). The other thing to test hardware would be to
see if you can connect to an unsecured network. However, I've seen one
instance where a failing wireless NIC would connect to an open network but
would not work with certificate-based authentication.

I'd try updating the driver. If that doesn't help, can you come up with
another wireless card to try on that machine? I bought a cheap USB one
just for diagnostic purposes, or maybe you could swap the one from the
working machine and see if that helps.

But none of this gets to why the auto enrollment is failing. I'm sure we've
already talked about this, but you've verified that auto enrollment fails
over a wired connection, right? If it weren't for the auto enrollment
error, and assuming matching configurations between the working and
non-working machines, I'd be confident in blaming hardware.

If IAS is logging failure, you're probably back to the certificate, or you
might get some other useful information from the log event.

Some resources:

Troubleshooting IEEE 802.11 Wireless Access with Microsoft Windows
http://technet.microsoft.com/en-us/library/bb457017.aspx

Windows Server 2003 Wireless Troubleshooting
http://technet.microsoft.com/en-us/library/cc773359.aspx

A Support Guide for Wireless Diagnostics and Troubleshooting (I've done the
eapol logging thing, etc. from this one. It made me wish I had taken the
day off to get a root canal instead).
http://technet.microsoft.com/en-us/library/bb457018.aspx




"Cuervolush" <Cuervolush@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:208B5A0B-3C96-42E3-8FCF-74D66D7669BE@xxxxxxxxxxxxxxxx
> Been busy doing service the last couple days but I have a little time > to
> revisit this problem today.
>
> Yes, AE was still failing after setting NLA auto and Windows Firewall > was
> always using domain settings I believe.
>
> Remote Registry is turned on and automatic on this PC. Ipconfig /all > shows
> the correct domain and DNS server and the only error I'm getting in the
> logs
> is the Autoenrollment failure.
>
> I went to the working PC and grabbed the certificate and installed it > on
> this PC. Unfortunately that didn't fix the problem, however now if the
> wireless is enabled on boot up the PC takes a really long time at the
> "preparing network connections" before it loads the desktop. If I > disable
> the
> wireless and reboot it starts up normally - but I still get the > autoenroll
> failure at every boot up.
>
> Any ideas?
>
> Thanks for the help!
>
> "Dave Nickason [SBS MVP]" wrote:
>
>> You did check that auto enrollment is still failing after setting NLA >> to
>> automatic, right? If before you made that change, the firewall was >> using
>> the non-domain settings, that could have been what was doing the
>> blocking.
>> Firewall blocking enrollment would have been my first guess, ISA >> second,
>> but
>> you've got both of those ruled out now.
>>
>> Just out of curiosity, is the Remote Registry service running on the
>> client
>> PC? I've seen RPC failures with that turned off, not in this context >> and
>> I
>> kind of doubt it's related, but worth a quick look.
>>
>> You're sure the workstation is properly joined to the domain, and in
>> ipconfig /all, it's pointing to the SBS for DNS? No other errors in >> the
>> logs?
>>
>> I do think you should troubleshoot and repair the auto enrollment >> issue.
>> However, that said, in the interest of getting the workstation >> connected,
>> can you export the cert from the working PC and import it to the
>> non-working
>> one? If you open Internet Options -> Content Tab -> Certificates, you
>> should be able to see the cert in Trusted Root Certification >> Authorities.
>> Export to a USB key or whatever, then just import it on the other PC >> by
>> r-clicking the exported file and choosing Install (or similar). Make
>> sure
>> to manually choose to put it in Trusted Root Certification >> Authorities.
>>
>>
>>
>> "Cuervolush" <Cuervolush@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:674A8D40-8A7F-4E90-AE85-FF58BBD39E37@xxxxxxxxxxxxxxxx
>> > Looked in the ISA console and "Enforce strict RPC compliance" is not
>> > checked,
>> > "enable" is checked.
>> >
>> > I will look through the link you've provided and see if I can find a
>> > similar
>> > issue.
>> >
>> > "Dave Nickason [SBS MVP]" wrote:
>> >
>> >> See if there's any help here
>> >> http://eventid.net/display.asp?eventid=13&eventno=2719&source=AutoEnrollment&phase=1.
>> >>
>> >> Also, on the SBS, open the ISA console. In the left pane, r-click
>> >> Firewall
>> >> Policy and choose Edit System Policy. In the resulting window, >> >> find
>> >> Authentication Services in the left pane, and under that, choose
>> >> Active
>> >> Directory. Is the box called "Enforce strict RPC compliance" >> >> checked?
>> >> If
>> >> so, uncheck it and click the Apply button at the top of the >> >> console.
>> >> The
>> >> "Enable" box should be left checked.
>> >>
>> >> Strict RPC compliance will block certificate auto enrollment, so >> >> that
>> >> could
>> >> be part of the problem if it's checked. If so, after making the
>> >> change,
>> >> reboot the workstation and see if you still get the error.
>> >>
>> >> Normally, I'd think having a working workstation would rule that >> >> out.
>> >> However, since others have been involved in the configuration of >> >> this
>> >> network, I'm thinking that one of them may have manually installed >> >> the
>> >> certificate on the working workstation, or that they enabled strict
>> >> RPC
>> >> compliance after that workstation was configured.
>> >>
>> >>
>> >>
>> >> "Cuervolush" <Cuervolush@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in >> >> message
>> >> news:02C0BA16-3DDB-45FF-8DE8-1FB93E25A621@xxxxxxxxxxxxxxxx
>> >> > Hi Dave
>> >> >
>> >> > I've checked in CP -> Windows Firewall but there is no >> >> > properties,
>> >> > just
>> >> > a
>> >> > General, Exceptions, and Advanced tab. No where on any of these
>> >> > screens
>> >> > do
>> >> > I
>> >> > see it say Domain or Non-Domain. NLA was started but Manual, so I
>> >> > went
>> >> > ahead
>> >> > and made it automatic anyway and rebooted without success.
>> >> >
>> >> > I just now found out that we are indeed running ISA, however we >> >> > do
>> >> > have
>> >> > a
>> >> > workstation in the office that is running wirelessly correctly.
>> >> >
>> >> >
>> >> > "Dave Nickason [SBS MVP]" wrote:
>> >> >
>> >> >> Please go to CP -> Windows Firewall and open the properties. At
>> >> >> the
>> >> >> bottom
>> >> >> of the first tab, does it say it's using your Domain or >> >> >> Non-Domain
>> >> >> settings?
>> >> >> If non-domain, please set the Network Location Awareness service >> >> >> to
>> >> >> Automatic startup and reboot the workstation.
>> >> >>
>> >> >> Do you have other wireless computers that are functioning as
>> >> >> expected?
>> >> >> If
>> >> >> so, please resist the temptation to mess with anything on the
>> >> >> server.
>> >> >> It
>> >> >> appears that auto-enrollment is failing on that one PC, which is
>> >> >> almost
>> >> >> certainly not a server or CA issue.
>> >> >>
>> >> >> Are you running ISA? That can prevent auto-enrollment, and the >> >> >> fix
>> >> >> is
>> >> >> to
>> >> >> disable strict RPC compliance. Post back if you need more info >> >> >> on
>> >> >> doing
>> >> >> that (and note it would only apply if there are no PCs where >> >> >> auto
>> >> >> enrollment
>> >> >> is working).
>> >> >>
>> >> >> "Cuervolush" <Cuervolush@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
>> >> >> message
>> >> >> news:01A6F8E8-6FC8-4E83-89F1-62177BDE0DFE@xxxxxxxxxxxxxxxx
>> >> >> > Our office is running SBS2003 and we recently had to rebuild a
>> >> >> > workstation. After the rebuild, I can no longer connect
>> >> >> > wirelessly
>> >> >> > to
>> >> >> > the server. In Event Viewer I get the following:
>> >> >> >
>> >> >> > Autoenrollment | Event 13
>> >> >> >
>> >> >> > Automatic Certificate Enrollment for local system failed to
>> >> >> > enroll
>> >> >> > for one Computer certificate. (0x800706ba). The RPC Server is
>> >> >> > unavailable.
>> >> >> >
>> >> >> > The wireless connection continuously tries to log in but comes
>> >> >> > back
>> >> >> > with
>> >> >> > status: Authentication Failed.
>> >> >> >
>> >> >> > I've searched a bunch of places with this error but haven't >> >> >> > been
>> >> >> > able
>> >> >> > to find an identical issue with a solution.
>> >> >> >
>> >> >> > Unfortunately I did not set this server up, and have somewhat
>> >> >> > limited
>> >> >> > knowledge on the server side of things but know enough to be
>> >> >> > dangerous. Any help would be much appreciated and I would be
>> >> >> > happy
>> >> >> > to
>> >> >> > provide any more information that would help in solving this
>> >> >> > problem.
>> >> >> >
>> >> >> > Thanks
>> >> >> >
>> >> >>
>> >> >>
>> >>
>> >>
>>
>>



.