Hi MoAbuDayyeh, I'm not sure whether you should update the article or outright invalidate it. When I first learnt about MDM via Intune late last year, I came across this article as an example of how to apply custom software policies by way of ADMX ingestion. Back then I don't remember Intune directly having Office 2016 ATs internally, but it didn't matter since we were only interested in controlling other software like Lenovo Vantage or Google Chrome; we ingested their ADMX templates accordingly and applied configuration profiles with no problems.
Come earlier this year, we decided to control some behaviours of Office apps, and referring back to this article, performed the same steps, and then found all our targeted computers stuck in pending status and never responding to any subsequent MDM commands thereafter. Effectively all the organisation's Windows computers were no longer manageable by us the IT operations team.
It is by the stroke of luck in experimenting with (manually deleting) the above Registry keys did we managed to wake our computers from their comas and have them responding to MDM again. This is however a huge DOS vulnerability in the Windows MDM client stack, and I have already alerted tech support to raise this problem to the relevant Windows development team.
Only later did we realise Intune now offered Office 2016 ATs out of the box, and that is the proper and safe way to configure their behaviours. This custom ADMX method is now completely dangerous to use.