See all of the top support solutions for our most common issues here
UPDATE: This issue has been fixed beginning with System Center 2012 Configuration Manager Service Pack 1 (ConfigMgr 2012 SP1).
In System Center 2012 Configuration Manager, the ‘Backup Site Server’ maintenance task may fail if the Backup Destination is set to a network share. An example is below:
When this happens, the following errors are logged:
Error: Backup folder \\MachineName\1234 does not exist or backup service does not have permission to access the folder.
If you look at the network share you see that the folder does exists and permissions are correct. So why does it fail? To know more, please download Procmon tool from here and capture a trace on both SQL and ConfigMgr site server with following filters while running the backup:
Process Name is ‘SMSSQLBkup.exe’ Process Name is ‘SMSBkup.exe’ Result is ‘BAD NETWORK NAME’
Once you see the error(s) mentioned at the start of this post, please stop the trace and look at the result.
If you look closely enough at Path column the backup task triggers a CreateFile operation on \\MachineName\123 which doesn’t exist. The correct path is \\MachineName\1234 . It drops the last character ‘4’ and as a result the backup task fails to complete successfully.
At the moment you can choose to use any of the following three workarounds to get the backup task to work.
1. Create a sub-folder under existing folder and configure the backup task accordingly. For example:
2. Save the files on local drive.
3. Create and use a network share on SQL Server instead.
NOTE This issue is schedule to be addressed in Service Pack 1
Additional information on Backup Site Server task can be found here.
Other links of interest:
The System Center 2012 Configuration Manager Survival Guide (en-US): http://social.technet.microsoft.com/wiki/contents/articles/7075.system-center-2012-configuration-manager-survival-guide-en-us.aspx
System Center 2012 Configuration Manager SDK: http://msdn.microsoft.com/library/hh948960.aspx
Get the latest System Center news on Facebook and Twitter:
App-V Team blog: http://blogs.technet.com/appv/ ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/ DPM Team blog: http://blogs.technet.com/dpm/ MED-V Team blog: http://blogs.technet.com/medv/ Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/ Operations Manager Team blog: http://blogs.technet.com/momteam/ SCVMM Team blog: http://blogs.technet.com/scvmm Server App-V Team blog: http://blogs.technet.com/b/serverappv Service Manager Team blog: http://blogs.technet.com/b/servicemanager System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials WSUS Support Team blog: http://blogs.technet.com/sus/
The Forefront Server Protection blog: http://blogs.technet.com/b/fss/ The Forefront Endpoint Security blog : http://blogs.technet.com/b/clientsecurity/ The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/ The Forefront TMG blog: http://blogs.technet.com/b/isablog/ The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/
Why would adding a sub folder fix the dropping of the last character? Is there a bug where it only checks the first 3 letters?
SQL server running on another server. Had the same error but creating the sub-folder didn't work. Procmon was showing access denied for System account to UNC share for smssqlbkup.exe process. Fixed by granting change share permission to System account for UNC share.
Also, before I was getting SMS Writer does not exist. vssadmin list writers didn't show it. Fixed by grating sql sysamin role to System login. Hope this helps someone!
Even with SP1 this is still an issue. after creating the subfolder in the share, sitebackup worked.
Ofcause i had to let the sql and site server/users have write access.
If the shares called XYZ and ConfigMgr truncates to XY, then just call the share XY as another work-around.
I want to kick that person who is responsible for that one. It is SCCM 2012 R2 and that issue is still in place.
I have this issue ...and now solved :) thank you people
This is still true within SCCM 2012 R2. Creating a subfolder fixed the issue. It's still removing the last character of the share (\\server\share looks like \\server\shar in procmon)
Two years later and an R revision and this isn't fixed? Seriously?
Are there any benefits to running the built in maintenance task in ConfigMgr 2012 vs using the SQL backup which gives you compression? Are any extra files backed up with the built in task?
This has got to be the silliest thing I have ever seen. Create a share on dpm F:\sccm\m then in site maintenance in sccm \\dpm\sccm\m -.- Anyway...on to the next sccm "fix" \\THANKS!\!
This is insane. We're running 2012 R2 latest updates etc and this is still an issue.Remote SQL backup fails to connect to the UNC share. Eventually I remembered this issue from *years* ago but initially dismissed it thinking there was no way it would still be a problem, but when I noticed recent comments from people still having it I tested anyway and yes, a subdirectory fixes it.