We help IT Professionals succeed at work.

SCCM 2012, deployment issue

So trying to test deploy an application to a single device.  I create a device collection for the one host, I created a new application and pulled the info from the .msi file.  Specified the path which is an SMB share, verified the server can access both the path and the file.  However the Content Status is failed, reason being:

The source directory \\netapp\mis\software\intercall for package MI100025 does nto exist.


But it actually does exist, the only thing is this is an application, not a package.  I don;t see any reference to MI100025 anywhere.
Comment
Watch Question

Distinguished Expert 2018
Commented:
SCCM 2012 turns *everything* into a package. When the application is distributed, it isn't distributed from the share. It is distributed via the agent from the package's internal location. This allows SCCM to do things like revision control and other similar things that pulling straight from the share would not allow. The share simply acts as a place for SCCM to compare the package against for both creating and revising the internal package.

Which brings us to your error. The distribution point role server and associated accounts must also have access to the share. If they do not, because of communications issues (DNS, etc) or because of permissions, the package cannot be created/updated, and the application will not get distributed.

Author

Commented:
Well the smb share has had an Everyone entry with read rights, as a test I upped that to modify, same error.
Distinguished Expert 2018

Commented:
Start with the event logs. Any glaring issues will stand out there.  If you don't see anything there, you'll need to dig into the actual product logs. The SCCM team really likes their own logging over event logs, so you can find exactly what is happening (good, bad, or otherwise) in those logs. Don't try to read them in plaintext though. The SCCM team also provides their own utility to read those log files. One nice thing about it is that it uses color coding to highlight problem issues. So you can fire up the tracer, open the log file, then try to publish the application and see the log file get written in real-time, with problems usually showing up in bright red.

SCCM is no joke of a product. It takes patience and knowledge, and there are few, if any, shortcuts when it comes to troubleshooting. Great power, responsibility, and all that.

Author

Commented:
I actually did see the same errors appearing in the distmgr log using that sccm log viewer tool thing.  Same error about how that source file doesn't exist.
Mike TLeading Engineer
Commented:
Hi,

It's a long shot, but before getting deep into log files are you sure the path is correct in ConfigMgr? I ask because you've put:

\\netapp\mis\software\intercall

Is mis the path or a typo and you mean msi? If it's a typo is it only here?

Open the application and edit the deployment type, the check the content tab. The content location has to be able to browse the path to your files (MSI). If you can't do that you have problems with the share or at NTFS level. I'm not sure if "everyone" even matters. SCCM does require specific permissions and accounts.

Mike

Author

Commented:
Sorry no the 'mis' is correct.. whoever the guy was before me named it for Management of Info Systems.. MIS.  Weird but yeah no it's not a typo.

And if the Everyone account has read rights then how could I give SCCM the access it needs?  I don't recall any of the services needing to run as special accounts.  The server is logged in with an account that had domain admin rights.

Author

Commented:
Anyone else?  I really need to get this thing figured out.