Few SEP clients leave the domain after upgrading 12.1 RU4 MP1b.

Do you mean the Windows or SEP Domain?

This is not an issue I've seen myself.  As Brian says, it'd definitely be worthwhile getting Symantec support on the case.

In the meantime, have you reviewed the SEP_INST.log (usually found in %temp%) for any related entries?

Open a support case

How to create a new case in MySymantec

http://www.symantec.com/business/support/index?page=content&id=TECH58873

Phone numbers to contact Tech Support:

Regional Support Telephone Numbers:

    United States: https://support.broadcom.com (407-357-7600 from outside the United States)
    Australia: 1300 365510 (+61 2 8220 7111 from outside Australia)
    United Kingdom: +44 (0) 870 606 6000

Additional contact numbers: http://www.symantec.com/support/contact_techsupp_static.jsp

http://www.symantec.com/business/support/index?page=contactsupport&key=54619

Its happening only on few windows7,XP machines

The NIC is disabled, but when SEP is uninstalled it get triggered up.

Installation and Upgrade went fine the issue is triggered post reboot.

The LAN and Wifi drivers are disabled.

@Khi02

Did you open a case with Symantec? If so, would you be able to provide the case number? We appear to be having the same on certain PCs. The network adpaters are disabled after the the reboot. Requiring us to reinstall the Symantec client.

Thanks,

Mike

So what exactly happens? Install/Upgrade to RU1 MP1b and upon restart the NIC goes bye bye?

After removing and restarting, it comes back? I've deployed to only 10 clients or so but have a full scale deployment on the roadmap so I'm just curious.

Yes, not on many PCs though. I have about 120 PCs upgraded so far. Only a handful have had the issue.

1. The PC gets the setup.exe file copied over

2. SEPM installs the new client, and requires a restart.

3. Upon the reboot, none of the network adpaters are visable.

4. Uninstall SEP/Reinstall SEP

5. Upon the reboot the network adpaters are back

We have Dell machines, I wonder what Khi02 is running.

Please help here.. What is the exact issue then?

Systems getting disjoined from domain? or Network adaptors getting disabled?

SEP 12.1 RU4MP1b Clients happily got installed on 1000 PC's in our network.

We had never faced this issue. Till now no one has reported

I have same issue 12.1 12.1.2 12.1.3 12.1.4..... upgrade.

first i upgrade server side, then use policy push to all client. client download liveupdate from Symantec server directly.

in evey upgrade process, i will have 0-3 computer(out of 140 pc) have all NIC disable and cannot enable unless i remove the sep client

it will happen after the sep client upgrade and only happen after  reboot.

I have Dell optiplex 390, 3010, 7010, 9020 desktop and dell Lattitude 6310 6410 6420 6430 6430 6330 7240 model

and mixed with some DIY pc with AMD athlon 64 X2 cpu with MSI motherboard

one laptop happen twice and other pc only happen once...

OS: windows 7 , windows 8.1 and windows XP

i cannot figure out how it happen but the solution is remove sep client.. reboot. install the client again....

P.S. Btw I did open a case with Symantec, Symantec support in taiwan teach me the solution 3 year ago. 

It might be Dell related. Interesting.

The network adpaters are disabled, not showing on the PC. Removing SEP and reinstalling the client fixes the issue.

I am with postechgeek

A bit more information.

From what I'm able to tell, the Intel 82579LM Gibabit Ethernet Network Adapter is the issue at least on 12.1.4112.4156. Not sure if this is strickly a Dell driver/SEP problem or an issue with the NIC itself. Meaning other vendors might be having trouble with the above NIC.  What I did to fix the issue -

http://www.simpletechs.com/simple-blog/windows-7-winsock-reset-not-working-initialization-function-inithelperdll-in-nshttpdll-failed-to-start-with-error-code-11003

Basically,

Delete these two keys -

HKLM/System/CurrentControlSet/Services/Winsock
HKLM/System/CurrentControlSet/Services/Winsock2

Insert winsock.reg and winsock2.reg into the regisrtry. Open up, cmd (command line) with administrator rights, issue netsh winsock reset, reboot.

Hope that helps!

It would be helpful to know if Symantec is going to release an update to resolve this issue. My upgrade process is on hold due to this.

We are having the same problem in our environment upgrading to version 12.1.4112.4156.  We are using the upgrade path via the SEPM to upgrade the clients in our environment.  This upgrade is critical because of the 0 day vulnerability found in all previous versions.  We have had a few hundred computers lose all network connectivity due to the upgrade, only after the reboot, and am in need of a more permanent solution than uninstalling and reinstalling this version of SEP.  We have had a few computers that have lost their network connections a week after the upgrade happened on the computer.

- Our upgrade is currently on hold until a solution is found
- Ethernet Adapter and Wireless Adapters are disabled until SEP is removed

Out of curiosity, for machine that lose their network connections, what gets returned by ipconfig?

For me, some of the PCs would show nothing from ipconfig. Meaning, you'll issue the ipconfig command and you'll just get "Windows IP Configuration". Other PCs, we would get the 169.x.x.x autoconfig IP address, as DHCP wasn't able to serve up an IP address.

Further, Symantec has released defintions to protect against this exploit along with the new version of SEP -

http://www.symantec.com/security_response/writeup.jsp?docid=2014-080607-5226-99

So, while it is important to upgrade to the latest version, you should be protected to some extant. Further, the vulnerability isn't accessable remotely only locally from what I understand.

Does anyone have new information on the NIC's dying when applying the zero-day update? I'm still in a holding pattern.

We ended up;

Upgrading to SEP 12.1.5337.5000 - Symantec seemed to fix the issues with this previous versions.

On the previous version the only thing I could find in common was the teefer.sys file missing from c:\windows\system32\drivers folder.  I uninstalled the NTP component, rebooted the computer, and reinstalled the NTP component.  This seemed to resolve the problem.  

Just so everybody is aware:  If you have UNC Folder Exceptions in your Exceptions Policy - You should remove these.

SEP 12.1.4112.4156 has some other issues associated with it

1.  If you have any exceptions in your policies that include a UNC Path - \\servername\foldername, you will start seeing every computer with that exception start talking to that path randomly.  

We had this particular problem and it caused over 40 second latency issues with our NAS devices.

Wow, good to know, thanks!

I wonder if this works differently in 12.1.5?

It's probably also worth noting that UNC paths are not supported as exceptions anyway:

http://www.symantec.com/docs/TECH197009

Right, I understand that UNC paths are not accepted or supported in any way.  Unfortunately, I inherited these in the policy when I took over this role and only caught this behavior because of SEP 12.1.4112.4156. I had 100,000 clients creating SMB2 handshakes about 100x per machine about 8 times a day basically creating a DDoS of my NAS devices.

.Brian - This doesn't happen with 12.1.5.  I have tested with 12.1.1101.401 and 12.1.5337.5000 and they don't have this behavior.  

How about for version 12.1.4013.4013?

Right after uprading from v11 to v12.1.4013.4013 some of the local machines not being able to authenticate to the domain and network was down, please advise.

You are require to upgrade in 12.1 RU5 for fix it.

Upgrade or migrate to Symantec Endpoint Protection 12.1.5

raju123 thanks for your reply. 
But i think this would not be the resolution, as we only experienced the issue on all winXP platform machines and why not on win7 platform?. Also, they also performed to temporarily fix network issue.

Netsh winsock reset catalog

Netsh int ip reset reset reset.log

Shutdown –f –r –t 0