SOLVED ConfigMgr PSS Running out of Disk Space

[leonardreeves]

Our PSS is running out of space on a drive that hosts the ConfigMgr application install along with SCCMContentLib, and the associated package directories (i.e, SMS_DP$, SMSPKG, SMSPKGSIG). The drive has a MBR partition so we don’t have an option to expand the disk. We have added an additional GPT partitioned disk as an overflow once the other drive has reached capacity after our Microsoft Support Engineer confirmed that the new drive will automatically take the next drive with the most space once the other drive is out of space.

Has anyone gone through this scenario? I’m curious on how the application side of things will be handled if the OS disk runs out of space completely. It seems content info would continue to be stored on the new drive but will the ConfigMgr logs, etc., continue on the new drive or will they be hindered due to lack of space? Would ConfigMgr retain some space for the application to reside on the current drive or would things spill over onto the new drive. Is there a way to reserve space for this or force the content to start using the new drive prior to running out of space?

Thanks in advance for any information.

 

[Garth]

ConfigMgr should never be installed c:\ when the C: run out of space it will stop working and you will need to logon locally (no RDP) and clean up the drive. Once there is free space you should reboot and let everything clean itself up.

If SQL runs out of space bad things can happen.

 

[leonardreeves]

Thank you for your reply. ConfigMgr was installed on our E: drive of the server, not our OS C: drive. We are going to run out of space soon due to large package content within our company and initially Microsoft had indicated things would automatically start using the next drive available but they did not realize that ConfigMgr was installed on the same drive.

Would we be able to add the NO_SMS_ON_DRIVE.sms file to this E: drive now before it runs out of space with room to grow for the application? Would this force the package information to use the next available drive (G) or would this break access to the package information already in place?

Thanks!

 

[Garth]

What does

due to large package content

What does this mean? are you talking about source files, content library, DP, etc.

Would we be able to add the NO_SMS_ON_DRIVE.sms file to this E: drive now before it runs out of space with room to grow for the application?

Putting no_sms_on_drive.sms file on the C: and E drive now would not hurt.

Would this force the package information to use the next available drive (G) or would this break access to the package information already in place?

No doing this would not break anything. or shouldn't.

 

[leonardreeves]

What does

What does this mean? are you talking about source files, content library, DP, etc.

Putting no_sms_on_drive.sms file on the C: and E drive now would not hurt.

No doing this would not break anything. or shouldn't.

Garth,
We have almost 2TB of data due to the amount of packages/applications for our company including numerous packages that are greater than 25GB each. We have a separate drive for our actual content. E: is a MBR partitioned drive that can't have any additional space added past the 2TB. We added another drive (GPT partition) as a place for the package data to continue. I've attached a file with our file structure on the E drive for clarification. ConfigMgr is installed in the "Program Files" directory and is the only application on E:. Everything else is mainly related to package info. We have the NO SMS file already on our C drive.

So we could add the NO SMS file and the content data would start using G: right away and then the previous packages on E: would not be impacted? The database would store the location of the previous files/data for E: and then any new content added would be referenced on G:? Just wanted clarification before we start testing. Thank you so much for your replies!

 

[Garth]

You can easily move source files at anytime. It will not affect existing deployment until you need to update them.
Putting the non sms on e: should mean that ConfigMgr will start to use the G: drive.

 

[leonardreeves]

Thank you for your reply. We will begin testing in our dev environment.

 

[leonardreeves]

You can easily move source files at anytime. It will not affect existing deployment until you need to update them.
Putting the non sms on e: should mean that ConfigMgr will start to use the G: drive.

Garth, we finally implemented the NO_SMS_ON_DRIVE.sms file to the existing E: drive where the SCCM installation and SCCMContentlib exist. This forced any new items to the SCCMContentLib\FileLib on the new G: drive as we expected.

Things seemed to be ok until we added a new DP and it started to send out the required Client packages and a couple test packages. They immediately went into retrying mode and when looking at the distmgr.log and pkgXferMgr.log logs, the system was unable to open the applicable .ini file under SCCMContentLib\DataLib to process the package. The fix was to update the package and all is well but we have over 1,500 packages and we would not want to update them all due to the excessive communications to all 43 DPs.

PkgXferMgr.log Error
CContentDefinition::GetFileProperties for \\?\E:\SCCMContentLib\DataLib\LQA0014D.1\PowerShell-7.0.3-win-x64.msi.INI failed. Error code = 0x80070003

This article is for the same issue but we are already at ver 2403. We did change from McAfee to CrowdStrike since the packages were created but we looked locally and from the console and no blocks/issues were found. (Article: https://forums.prajwaldesai.com/thr...tentdefinition-getfileproperties-failed.5707/)

Is there a workaround where the .ini files would be accessible? The .ini files having Administrators with Full Control. I'm not too familiar with the datalib side of things so any recommendations would be appreciated.

Thanks in advance!
Leonard Reeves

 

[Garth]

So to be clear you change the Package source location for a package? It theory (although I trust the source, I don't believe it fully) if not files changed between the deployments, the source files will not get redeployed to DPs. They will check hash of their compressed version of the hash and not download the new package. Only DPs without the files will be re-deployed. This of course is easy enough to test, change one package and watch the logs.

 

[leonardreeves]

So to be clear you change the Package source location for a package? It theory (although I trust the source, I don't believe it fully) if not files changed between the deployments, the source files will not get redeployed to DPs. They will check hash of their compressed version of the hash and not download the new package. Only DPs without the files will be re-deployed. This of course is easy enough to test, change one package and watch the logs.

Garth, sorry if I'm not clear on our situation. We placed the NO_SMS_ON_DRIVE.sms file on the drive (E drive) that contains the SCCM Application along with the SCCMContentLib and SMSPKGSIG folders.

This forced the application to create a new SCCMContentLib on the new drive (G drive) along with a new FileLib folder with new content under this folder as it was added since the file add. The other folders referenced on the E: drive are still in place and update as required.

The issue I noticed is when a new DP is added that never had the package or its content, it has an issue accessing the .ini file under the SCCMContentLib\Datalib folder and errors out. The fix is to update the package which resolves the issue but does start communications to all DPs having the package. I don't think it is sending any data based on the logs, just communicating to ensure they have the right package as you mentioned. We are just concerned that we would have to update 1k+ packages if we add a completely new DP and looking for a workaround to that situation.

Thanks!

 

[Garth]

Garth, sorry if I'm not clear on our situation. We placed the NO_SMS_ON_DRIVE.sms file on the drive (E drive) that contains the SCCM Application along with the SCCMContentLib and SMSPKGSIG folders.

This forced the application to create a new SCCMContentLib on the new drive (G drive) along with a new FileLib folder with new content under this folder as it was added since the file add. The other folders referenced on the E: drive are still in place and update as required.

The issue I noticed is when a new DP is added that never had the package or its content, it has an issue accessing the .ini file under the SCCMContentLib\Datalib folder and errors out. The fix is to update the package which resolves the issue but does start communications to all DPs having the package. I don't think it is sending any data based on the logs, just communicating to ensure they have the right package as you mentioned. We are just concerned that we would have to update 1k+ packages if we add a completely new DP and looking for a workaround to that situation.

Thanks!

There will be no work around. if it is only checking the source check sum at each DP, this will not be alot of traffic.

 

[leonardreeves]

There will be no work around. if it is only checking the source check sum at each DP, this will not be alot of traffic.

Ok thanks. I was hoping to find a way to kick off the "Update Distribution Points" for the impacted packages via script versus touching each package.

Do you know the impact if we removed the NO_SMS_ON_DRIVE.sms file that we added from the E drive and returned the configuration to the previous? Would things return to normal minus the new data on the G drive or would this cause issues?

UPDATE: We removed the NO_SMS_ON_DRIVE.sms file in our QA environment from the E (also Applications drive) and it resolved the access to the files under Datalib issue. We're hoping the system will continue to use the larger free space drive going forward and will do some testing to see if that works.

Thanks!