Here is a free PDF guide documenting my custom solution for deploying and managing custom templates for Microsoft Office applications using SCCM. The solution takes advantage of SCCM’s Compliance Settings feature both to deploy and to manage the lifecycle of custom Office templates in your environment.
Deploying Custom Microsoft Office Templates with System Center Configuration Manager
Great post but just 1 question, would it be possible to use a OneDrive instead of a file share for the Remote Template Store?
That would be more difficult certainly. It would require that you provide some means to authenticate with OneDrive in the PowerShell script.
i have tried to follow it, but i get i 0x80070001 incorrect function on deployment when testing it.
You can check the DcmWmiProvider.log on the client to find any errors returned by the PS code. Also try running the code manually in the appropriate context as it will write output for the activities it performs, to help troubleshoot.
I have tested implementing this compliance rule. The rule work as intended. It copies template, preview and thumbnails the Program Files (x86). Copies XML file to users App data and all Reg entries a populated.
However when i try and open templates, i don’t see any thumbnails and i get an error to tell me that the template file cannot be read. Template open file if i open it directly.
Any idea what could be wrong?
Can you post the error?
Hi Trevor, Thanks for your reply. I figured it out in the end. I copied the XML from the guide and the formatting was incorrect. Once I fixed the XML formatting everything worked perfectly. Brilliant guide 🙂
Great, thanks for the feedback 🙂
Due to poor network links. I have a package that copies all the files you have in the share to a local store. I then use your compliancy setting to use that local store. So far seems to be working nicely
Hi Trevor, thank you for this awsome guide. I built the setup exactly as you described, but for some reason the machine setting discovery always returns “Compliant” (looking at the configuration baseline report on a testmachine), and therefore it doesn’t run the remediation script. I ran the discovery script locally on a test machine, and it returned “Not-Compliant on local template path”. This only happens for the machine-based setting, the user-based script discovers and remediates fine each time. Any ideas?
Hi Tim, that error is returned when the machine discovery script is testing the path to the local template directory. The template directory is determined by OS architecture like so:
# Set local template path by architecture
If ($OSArch -eq “32-bit”)
{
$LocalTemplatePath = “$env:ProgramFiles\Microsoft Office\Templates\$RootFolderName”
}
If ($OSArch -eq “64-bit”)
{
$LocalTemplatePath = “${env:ProgramFiles(x86)}\Microsoft Office\Templates\$RootFolderName”
}
Set the root folder name and run that code to find the cause of the error.
Hi Trevor, thanks for your response.
When I run the discovery script manually, it returns “Not-Compliant” because the root folder and files are not there, so it is doing what it is supposed to do.
If I manually run the remediation script, it copies all the folders. If I run the discovery script again, it returns “Compliant”.
Both scripts run as they are supposed to, but for some reason SCCM always interpreters “Compliant” from the discovery script, even when the discovery script (when run manually) outputs not-compliant.
Therefore it never runs the remediation script.
Mmm it should not do that. Is there anything useful in the dcmwmiprovider.log? Does the discovery script run to completion or does it timeout?
It looks like it has something to do with the fact that it is a machine discovery, and the impersonation it runs in. The user discovery runs fine each time, kicks off the remediation script when required.
As a test, I changed the values in the machine discovery script from C:\program files to a location in the %appdata% folder (like in the user discovery script), and checked the “Run scripts by using the logged on user credentials” checkbox.
After that, the discovery script returned not-compliant and the remediation script kicked in, as expected.
I found a TechNet post where someone reports more or less the same issue: https://social.technet.microsoft.com/Forums/en-US/33fe010b-466a-49f9-ba06-d765246e2c98/powershell-discovery-script?forum=configmanagersecurity
I will adjust the script a little to find out weather the proposed answer in this tread will work for this script as well.
Nope, did not work… Changed these lines:
{
“Not-Compliant on remote provider existing locally”
Break
}
to
{
return 1
}
With a return 0 at the end of the script. Again, works fine when ran locally, but SCCM still sees the output as “Compliant”, looking at the report on the machine. Very confusing.
After some more troubleshooting, I got it working by using the following workaround:
Used “C:\users\public\documents” as the local root template store.
Changed all the machine script references form C:\program files or C:\program files (x86) to C:\users\public\documents and eliminated the bit checks.
Changed the machine discovery script to run in the user context.
Updated all XML’s to include the new path.
This did the trick for me, might help someone else as well. I can send you the updated script if you want, just let me know.
You can also use the C:\ProgramData\Microsoft\OFFICE\Templates location for the local template store. This avoids any potential issues with templates when working with both x86 and x64 Office in your environment. Wouldn’t work running in user context though, unless you grant users access to that location.
Yes, running the baseline in machine context is the issue for us (still cannot explain why, but whatever), so for now the workaround did it for us. The x86/x64 check worked fine, I just eliminated it because it is no longer required when using C:\users\public\documents.
Anyway, thanks again for the great solution you are describing here, it definitely helped us by providing a great deal of flexibility and very easy lifecycle management.
Thanks, glad it helps 🙂
Hi Tim,
I am in the process and implementing this in my environment and found it to be a little tricky due to the mixed 32 and 64 bit Office installs. I think your modifications to the scripts will do the trick for me and if you wouldn’t mind sharing them, I’d appreciate it. I could modify them myself but if you have already done the work, it will save me some time. I know your original post is a little old and not sure if you will see this but it is worth a try.
Thanks
Hi Tim,
I am in the process and implementing this in my environment and found it to be a little tricky due to the mixed 32 and 64 bit Office installs. I think your modifications to the scripts will do the trick for me and if you wouldn’t mind sharing them, I’d appreciate it. I could modify them myself but if you have already done the work, it will save me some time. I know your original post is a little old and not sure if you will see this but it is worth a try.
Thanks