The environment variable PATH (combined SYSTEM PATH and USER PATH) can be tricky to parse if you want to check for each folder it contains. This is due to the support of various formatting styles. For example, this is a valid PATH statement:
C:\WINDOWS\;"C:\Path with semicolon; in the middle";"E:\Path with semicolon at the end;";;C:\ProgramFiles;
It’s been many years since I read that SQL databases should use an NTFS volume formatted with at 64KB file allocation unit size (block size). So long that I didn’t remember why or if it is still considered best/good practice. It appears that it is according to Microsoft and the foremost authority on SQL with ConfigMgr.
Several ConfigMgr scenarios require that the content Source Path be changed. This typically includes migrating to a new ConfigMgr environment (2007 to 2012, 2012 to Current Branch, etc.), and simply moving the source content to a new location such as a DFS Share or low-speed NAS device.
Updating the Source Path can be done manually via the ConfigMgr console. For Packages, Software Update Deployment Packages, Drivers, Driver Packages, Operating System Images, Operating System Upgrade Packages, Boot Images, and Virtual Hard Disks, just add the Pkg Source Path or Package Source Path column to the console view to review the paths, then edit the object’s Source Folder in the Data Source tab.
However, for Applications, you’ll have to step through each Deployment Type on each Application, view the properties and modify the Content Location in the Content tab.
This is all painfully slow if you have more then a handful to deal with. So, automate it!
The community has developed at least 5 solutions to this including