I recently spend some days having fun with good old on premise software and it really makes one appreciate infra as a code and provisioning everything in the cloud, fast. 🙂 The problem is that most of the vendors of on prem software have more focus on introducing their cloud offerings and do not want to invest heavily into improving their on-prem installers to accommodate for myriad of edge-cases even if you have support contract of some sort, and if you don’t, then you some times doomed to fight all sorts of obscure errors which can drive crazy any normal person, except for those who strive to convert oneself to a guru in a very narrow and obscure details of proprietary software combinations… Such type of expertise makes one shine on some rare occasions/in the specific niche but amount of efforts one has to spent learning how to fight small strange problems with obscure solution can be demotivating as it is normally all edge and isolated cases which eat up your time to discover solutions which are often not reusable. Well if in process of fighting those you have time and enough of supporting materials to get understanding of how it all works it is one story (good learning/reusable knowledge), but if you are in a get this thing provisioned ASAP mode then you probably revert to fix it by all means without time to think through why fix was needed and what is the best solution – that’s a bad use of precious time, but sometimes there are no other options. Cloud apps and services has their own share of little problems but really cloud really removes bulk of initial setup and provisioning issues – and if there are real problem with that then it is something that vendor will be willing to fix in the most of the cases. This is because to qualify for being cloud software supposed to offer you on-demand self-service provisioning capabilities which have to work with no human intervention beyond “I’m requesting XYZ” from the consumer side. Anyhow that was a bit of self reflection after setting up mix of software on a demo box which involved K2 5.4, SQL 2019, SharePoint 2019 with someone putting RPA software and Office 365 on the same box in parallel – amount of strange errors was higher than normal this time. So just a little blogpost to take a note of couple of problem/solution pairs in case I will run into this again or someone else will run into those.

One of the errors I got was this one – “We’re sorry, Microsoft Office installer encountered a problem because you have these Click-to-Run installer based Office programs installed on your computer”:

This error basically blocks SharePoint 2019 or SharePoint 2019 installer – you can’t nor install nor repair, so for the first time I did removed Office 365 to do a SharePoint 2019 repair, but later on with eager RPA developer putting Office 365 installation back in no time I decided to search a way to avoid removing Office 365 to run SharePoint 2019 language pack installer. To remove this blocking warning you need to locate your Office installation registry subkey, which for x64 bit can be found under the following path:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\O365BusinessRetail – en-us]

Final part/subkey may vary depending on exact Office version you have, and x86 installation entries can be found under HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ subkey. So once you located right registry subkey you will need to add RED_DWORD parameter with name SystemComponent and value of 1 (see screenshot below).

That should suppress blocking warning and it worked for me in my test environment. Surely MSFT introduced this blocking warning for a reason and you are free to investigate when it is better to avoid removing that warning and seek other ways of solving this. I would in my case it was TEST/DEV environment where developer need an office right on the server which IMO should be avoided in any type of PROD deployment, so this fix was OK for my scenario.

In addition to the above mentioned error, at the final stages of SharePoint 2019 apps environment set up I run into the problem where all was seemingly configured correctly but K2 for SharePoint app page was giving me 404 or other connectivity errors (depending on bindings configuration), to get to that stage I made use of my old blogost and this script (it seems some of the required service apps can only be added with PowerShell), but somehow in my previous write ups I’ve missed or did not mentioned requirement of putting a wildcard into host value of IIS site created for a web app which hosts app catalog. I was sure that it can work with require SNI and a host name (vaguely remembering that it should not be possible :)), especially after looking at another environment where it indeed works that way, but after resolving this problem by switching to * host and no SNI binding, I realized that other environment had SharePoint Routing Web Application which was responsible for magic of making it all work. My only problem is that I did setup that environment either and now not even remember this part of config.