+ a billion. There are many oddities to be had because of channel auto-selection, especially depending on the frequency it performs the congestion check. Like servers, hard code it and deal with connectivity issues as they come.
-- ME2 On Tue, Oct 19, 2010 at 7:13 AM, Raper, Jonathan - Eagle < jra...@eaglemds.com> wrote: > **headdesk** > > > > IMO…never set your APs to Auto. Spend the time, or the money, or both, for > a decent site survey. Use only channels 1, 6, & 11, and lay your APs out so > that the APs on the same channels are not close to each other, because too > much signal overlap on the same channel will cause RF collision. > > > > Once setup, review periodically (quarterly, semi-annually, annually, etc) > to make sure no one has added any wireless in the area that would interfere > (or use the utilities built in if you have something like Cisco Wireless > Control System with centralized controllers). Keep in mind that RF noise is > additive. Any NON 802.11 RF signal will be considered noise, and the more > there is, the more it will work against your 802.11 equipment - decreasing > the signal-to-noise ratio (SNR) and increasing the chances of wireless data > traffic corruption. > > > > Side note: There are enough channels in the 802.11a spectrum (5GHz) that > channel plans are not usually necessary. > > > > Furthermore…..Anyone dealing with wireless networks need to understand SNR > (Signal to Noise Ratio) and how it impacts wireless performance. It’s like > trying to talk with another adult in the same room when you have a couple of > chatty children in the same room. You can carry on a conversation with > another adult across the room, but if you double the number of children, you > have to raise your voice. Add enough children, and no matter how loudly you > shout, the other adult will never hear you, and vice versa… > > > > Here’s a link that does a good job of explaining it and provides some > guidelines: > > > > wi-fiplanet.com - How to: Define Minimum SNR Values for Signal > Coverage<http://www.wi-fiplanet.com/tutorials/article.php/3743986/How-to-Define-Minimum-SNR-Values-for-Signal-Coverage.htm> > > > > Hope this helps. > > Jonathan L. Raper, A+, MCSA, MCSE > Technology Coordinator > Eagle Physicians & Associates, PA* > *jra...@eaglemds.com* > *www.eaglemds.com > ------------------------------ > > *From:* John Hornbuckle [mailto:john.hornbuc...@taylor.k12.fl.us] > *Sent:* Tuesday, October 19, 2010 8:50 AM > *To:* NT System Admin Issues > *Subject:* Update: Group Policy Problems Over Wireless > > > > No firm resolution on this yet, but possibly a bit of progress. > > > > I kept thinking about the problems we were having in this lab. The > computers are the same computers we had in the lab last year, and last year > we didn’t have these problems. So, what changed? Two things: we replaced the > WAPs that serve the lab with newer models, and more WAPs were installed in > that area of the building. > > > > So I got to thinking that maybe the issue was an incompatibility between > Broadcom NICs and the new WAPs, or an issue caused by too many WAPs being in > the same vicinity. But we have another lab in a different area of the > building that has the exact same WAPs and the exact same computers—but no > problems. So that left the latter possibility—lots of WAPs stepping on one > another’s toes—as the prime culprit. > > > > The WAPs are Cisco/Linksys, and they all default to the same channel. I > changed the ones in the area that was having the problem to “auto,” but that > didn’t seem to really help. So next I forced the WAPs that serve the lab to > “g” rather than “b/g/n.” As moment, everything is working fine. My tech and > I will be watching throughout the week, and if things are still working > after a few days we’ll consider the issue resolved. > > > > > > John > > > > > > *From:* John Hornbuckle [mailto:john.hornbuc...@taylor.k12.fl.us] > *Subject:* Group Policy Problems Over Wireless > > > > Short version: > > *Is there a trick to improving group policy processing when accessing the > network wirelessly?* > > > > > > Long version: > > We have a lab with machines that have Broadcom wireless NICs in them. Vista > OS, connecting to Server 2008 R2 DC. > > > > I’m trying to deploy a piece of software to these machines via Group > Policy. I have things setup so that if the machine is a member of a certain > group, the software is deployed. Unfortunately, it only worked correctly on > one of the machines—on all the rest, the software isn’t being deployed. > > > > So I connect to any of the machines that didn’t get the software, and run > gpresult. It doesn’t show me that those machines are members of the group > that gets the software. But I know they are; I’ve confirmed in ADUC on the > DC. They’re just not picking up group membership. > > > > Looking at the event log for events that happen around startup, I see > things that make me think group policy processing is trying to happen prior > to the wireless network being initialized. Things like: > > > > Event ID 5719 (There are currently no logon servers available to service > the logon request.) > > Event ID 129 (NtpClient was unable to set a domain peer to use as a time > source because of discovery error.) > > Event ID 1129 (The processing of Group Policy failed because of lack of > network connectivity to a domain controller.) > > > > Connectivity to the DC is fine once you get the [Ctrl] + [Alt] + [Del] > window. You can log in (including as someone who has never logged into the > machine before), ping the DC, browse to \\domain\syvol, and so on. It’s > just that at that point, group policy processing seems to have given up. My > machines aren’t figuring out that they’ve been added to a new group. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > > NOTICE: Florida has a broad public records law. Most written communications > to or from this entity are public records that will be disclosed to the > public and the media upon request. E-mail communications may be subject to > public disclosure. > > > ------------------------------ > Any medical information contained in this electronic message is > CONFIDENTIAL and privileged. It is unlawful for unauthorized persons to > view, copy, disclose, or disseminate CONFIDENTIAL information. This > electronic message may contain information that is confidential and/or > legally privileged. It is intended only for the use of the individual(s) > and/or entity named as recipients in the message. If you are not an intended > recipient of this message, please notify the sender immediately and delete > this material from your computer. Do not deliver, distribute or copy this > message, and do not disclose its contents or take any action in reliance on > the information that it contains. > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to listmana...@lyris.sunbeltsoftware.com > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
