Endpoint Protection

Hi All,

I have a very strange issue that is occuring with the location policies in relation to the Device Control Policies.

I recently upgraded our clients and End Point server to version 11.0.6100.645. The reason for this was to overcome the issue that the Application and Device control was having with wireless N adapters.

What I currently have set up is a policy for clients that are on the network via the cabled ethernet port and when they are off the network using the wireless adapter.
The policy detects which location it is in, Ethernet or Wireless, and if it is in the Ethernet location it will disable the wireless adapter. Once the ethernet adapter is disconnected the wireless adapter is re-enabled and communication can resume with that adapter.

The issue that is occuring is this. When I boot up the laptop WITH a patched in ethernet cable and then take the cable out after it has successfully booted up the location services change correctly and the wireless adapter is re-enabled. If I put the ethernet cable back in, the wireless adapter gets disabled as it should. All this works as it should. The problem comes in when the laptop is booted up WITHOUT a patched in ethernet cable. When this happens the location services go crazy and keep bouncing between the ethernet and wireless locations set. As a result the wireless adapter keeps getting disabled and re-enabled continuously. As soon as I put in the ethernet cable the location services stop bouncing and stay in the ethernet location. Take out the cable, it starts bouncing again.

I have tried changing the policies to just block wireless traffic instead of disabling the wireless adapter. All works fine if the laptop is booted up with a patched in ethernet cable. Without a patched in ethernet cable it NEVER blocks wireless traffic when the cable is put in AFTER it has booted up.

Has anyone come across this ?

This happens on 2 different model laptops with different wireless chipsets, so it is not a hardware issue.

Just on another note this used to work perfectly in 11.0.6005, but I need the latest version for the Wireless N Fix.

Any help will be greatly appreciated

I think you need to immediately open a support  case...

Very intresting  ....

I have a case open with them. Been open for about 3/4 weeks now and they cannot figure it out. They are looking through the logs at the moment. Was just hoping someone might have had the same issue.

Is there a way you could  give me the case number? Send it through email...

Just a couple questions:

1. On the group in question, under Policies > General Settings, do you have "Remember Location" checked or unchecked? 

" Remember Location - Clients will start in the same location they were previously using."

2.  What are the specific conditions you're using for your location awareness policy. 

(ie what are the criteria you set out for the "wireless" location and "wired' location.) 

3.  Which location is set as the default location. 

To answer your question Citali,

1 - Have tried it with Remember location and it just does the same thing if the last location was wireless.

2 - Ethernet Location :

• Type - Network Connection Type
• If the client computer uses the network connection type specificied below
• Ethernet

     Application Device Control policy :

• Blocked Devices - both types of wireless chipsets Intel 4965 and Intel 5100

     Wireless     

• Type - Network Connection Type
• If the client computer uses the network connection type specificied below
• Wireless

      I have even set nothing in the wireless location and it still does the same thing

3 - If I set the Wireless as the default policy it still does the same. If I set another location with nothing set as a default policy it still does the same thing bouncing between wireless and ethernet

An additional question.

Does your wireless location have an application and device control policy?  What I mean is, are you disabling any devices, applications, etc with a policy on that location? 

If you have the policy checked but you don't have any rules applied the driver gets disabled.  Your entire location setup seems to rely on the functionality of application and device control to disable the wireless NIC when an ethernet cable is plugged in.  If you shut down the system when the policy has no rules to apply, the driver won't run on the next bootup.  This would probably cause a race condition where both devices could theoretically be enabled and in use in situations where the driver isn't running. 

I suppose you could verify this by querying the application and device control driver when the issue occurs.  Run this from command line. 

sc queryex sysplant

This will tell you if the driver is running.  If the driver is disabled then you'll need to make sure that all of your locations have application and device control policies. 

However, given the fact that application and device control does not run on 64bit systems, I personally would not setup my criteria in this fashion.  But perhaps I missed something about your setup. 

Interesting issue.  I have not seen that with our location awareness but will be testing it in the morning. 

One suggestion I would make is to have a third 'location' setup for no network access that opens removes all previous ACDC policies.  I noticed when I was testing a couple of months ago that strange things would happen once and awhile with location awareness.  Once I set that policy most of my issues went away.

I added another location as you suggested and it still does the same thing. Does not even look at the 3rd policy even if I set that policy as default in case of conflict

I have updated drivers. still no go.

Citlali - The driver does get disabled as it should by the Device Control Policy (When the ethernet cable is plugged in - as it should), but with the cable out the Policies are re-enabling it and disabling continually. This is running on a 32bit system.

Jason,

My point is that you don't want the sysplant driver turning on and off.  The driver needs to stay enabled the entire time so that when you switch policies, the new policy can get applied.  If the system boots up with the driver disabled, when the policy to enable application and device control gets applied, it will take a reboot before the driver gets enabled. Since your entire location setup requires that application and device control function in order to disable the wirelesss NIC, you should setup an application and device control policy on the wireless location as well.  It doesn't matter which rule you enable.  You could probalby just use the built-in rule to protect the hosts file.   Try this and see if the locations continue to switch. 

Citali,

I did what you said and it is still bouncing.

When running that query it says the sate is Running for Service_name sysplant.

I enabled the device control policy to block access to the hosts file as you suggested and it still bounces.

Darn, I was really hoping that was it.  At this point it sounds like a bug with the the logic in detecting wireless connections.  They changed the way this was done in RU6 MP1 according to the release notes.  You'll need to continue to work with support to get this submitted to their development team. 

FYI.  I had a case open regarding some odd behaviour with location awareness and wireless disabling/renabling... Wireless didn't always 'come back' and Symantec confirmed it is a bug in the latest build MR6MP1.

Jason, we are running SEP v11RU6a.  I have two location awareness policies set up for our laptop groups that do not seem to have this flapping behavior.  Maybe you could try configuring yours as I have done and see if it makes any difference in your environment.

Location 1 name = External Devices(Set this location as the default location in case of conflict)
LU policy is configured to use the Symantec LiveUpdate server only.
(No condition is set here.)

Location 2 name = Network-connected Devices
LU policy is configured to use the default Management server only.
(Condition configured = "Client can connect to Management server")

Perhaps this alternate config will help you.

+++
jdk

We're on 11.0.5.   And have been having trouble with location awareness and device control also.

I really don't understand why Symantec can't define ethernet better.   It shouldn't match vmware.   It shouldn't match 802.11n.

I had 11.0.6 out to a few computers, but as you've found it seems to have worse location awareness/ device control issues with wireless.

Seems like I'm always waiting on a new release.