SSR 2013 Agent is holding a connection open on a CIFS share

Yes: Create a post.cmd with a net use * /d /y

The connection stays established even after running your suggested command -- probably the SSR client sees it stopped and reconnects?

Doing a "netstat" shows it connect both before and after the Net Use /Delete... :

TCP    10.1.1.8:52602      DellDR4100Device:microsoft-ds  ESTABLISHED

The SSR Management server doesn't even show up in the list of Active Connections.

This may help: http://www.symantec.com/docs/TECH163260.

The article you linked exactly matches my issue.  Unfortunately the connection stays open even after stopping the SSR service; I feel like a cat chasing a red dot laser.

None of the workarounds will work for me:

1. The vendor will not increase the number of connections

2. Cannot buy more CALs (because of #1)

3. Stopping VProSvc does not break the connection

4. Rebooting client machines is not an option

I checked with a colleague who dealt with a customer that ran into this issue a while back.

It seems as though a service restart doesn't actually help, so the article I mentioned needs to be modified.

If the other workarounds are not acceptable (and I can understand why), the only other solution I can think of is to increase the maximum number of concurrent connections to whatever you are backing up to. Is that possible?

Unfortunately I can't get the maximum number of concurrent connections changed on the device.  It's a Dell DR4100 backup and deduplication appliance -- evidently each connection uses a huge amount of cpu for deduplication and compression so they've limited connections to 32. If we were using Backup Exec or some other BU software, it would be perfect since only one connection would be used -- this is the intended usage. The DR4100 is screaming fast.

If we could get SSR to release each connection when it finishes a machine's weekly backup, it would be super easy to be able to stagger the backup times.  They go very fast and we only have about 60 machines.

The only way I've found to break a connection is to put a bad password in when setting up the backup.

Did you run the command as a post.cmd or when beeing logged on to the machine. It needs to be run as SYSTEM.

I set up a Post-recovery-point command file with the following; hope it's alright to use the wildcard "fn*" so I don't remove legitimate connections:

net use fn* /D /Y

After running the job, it doesn't appear to have broken the connection with that command.  I think SSR must poll to make sure it's not released because the remote machine says it's been connected 61+ hours.

Is it possible it doesn't run as System?  Maybe it uses the credentials that I used to access the batch file?

I sure wish SSR would release connections -- I don't mind keeping the connection to the Management Server, but keeping the backup location UNC open throws everything off.  Maybe they can't figure out a way to close one but keep the other open?

The storage unit will be getting a software update that's supposed to increase the number of connections to 64, which will be plenty for my purposes.  I'm sure others will still be restricted.

Thank you for all your suggestions!

Sorry, your're right. It is run in the context of the user you use to access the NAS device.