Tag Archives: SharePoint App Catalog

Unable to run SharePoint 2019 installer when Office 365 is installed on the same machine

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).

Adding SystemComponent parameter

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.

Provisioning SharePoint App Catalog in SP 2013/2016

Starting from SP 2013 we have to have application catalog in order to host SharePoint hosted apps which is part of SP App Model which replaces solutions you used to use in older versions of SharePoint.

This topic is documented both by MSFT and by IT community but the problem with any documentation that you have to internalize it to get clear understanding and even properly written explanations sometimes does not click for you until you do some hands on practice and, yes, internalize this information. Recently I finally decided to do some practice and create an app catalog from scratch in my test environment as well as jot down the steps which are easy to follow and more appropriate for those whose sole question is “I need an app catalog. How can I quickly set it up?”

Here is the steps:

1) Provision required service applications. You need to have Subscription Settings Service and App Management Service Applications provisioned and running. You need to use PowerShell to provision service apps:

Add-PSSnapin Microsoft.SharePoint.PowerShell

#Adjust -Identity parameter as necessary

$msa = Get-SPManagedAccount -Identity conundrum\sp_serviceapps

#Create the App Management Service Application

$AppPool = New-SPServiceApplicationPool -Name "AppManagementAppPool" -Account $msa

$AppManagement = New-SPAppManagementServiceApplication -Name "App Management Service" -ApplicationPool $AppPool

$AppManagementProxy = New-SPAppManagementServiceApplicationProxy -Name "App Management Service Proxy" -ServiceApplication $AppManagement

#Create the Subscription Settings Service Application

$AppPool2 = New-SPServiceApplicationPool -Name "SubSettingsAppPool" -Account $msa

$SubSettings = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service" -ApplicationPool $AppPool2

$SubSettingsProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $SubSettings

Once this script has been executed make sure to start services from CA.

K2 - App Catalog required services

2) DNS part. You have to have separate app domain or wildcard CNAME Ā entry in existing domain (the latter is no go in production environments for security reasons). We need wildcard DNS entry just because we want dedicated DNS domain names for our apps but we don’t want to create new DNS records for each and every app which comes online. We also want to have our apps running in their own isolated DNS domain (separate TLD) outside of SharePoint – this is better isolation approach which comes with SP app model.

You can just create wildcard CNAME record in existing domain like that:

K2 - App Catalog Wildcard CNAME entry in existing domain

Once again this is “no go” from security POV and you either want separate TLD or sub-domain for your apps. Steps below describe how to create DNS sub-domain and wildcard CNAME entry in it.

Start DNS Manager snap-in, right-click on Forward Lookup Zones and select “New Zone…”

K2 - App Catalog creating sub-domain 1

Next you just go through New Zone wizard mostly accepting defaults with exception of the page where you have to specify your sub-domain name, which in my case is “apps.conundrum.com”:

K2 - App Catalog creating sub-domain 1 K2 - App Catalog creating sub-domain 2 K2 - App Catalog creating sub-domain 3 K2 - App Catalog creating sub-domain 4 K2 - App Catalog creating sub-domain 5 K2 - App Catalog creating sub-domain 6 K2 - App Catalog creating sub-domain 7

Once DNS sub-domain is created you can create wildcard CNAME entry which have to point to your SharePoint app server in your parent/main domain:

K2 - App Catalog sub domain CNAME record 1 K2 - App Catalog sub domain CNAME record 2

Here is how end result should look like in DNS Manager:

K2 - App Catalog sub domain CNAME record 3

What it gives you in the end? Thanks to wildcard CNANE DNS entry in sub-domain you can ping any name in this sub-domain and it always will be resolved to your SharePoint app server IP. Example:

K2 - App Catalog sub domain CNAME record - test

3) Create new App Catalog site collection. Go to CA > Apps > Manage App Catalog:

K2 - App Catalog creating App Catalog 1

Then selectĀ Create a new app catalog site and click OK:

K2 - App Catalog creating App Catalog 2

On the next page specify required values – Title, Web Site Address, Primary Site Collection Administrator and End Users, and click OK:

K2 - App Catalog creating App Catalog 3

After this App Catalog sites collection will be created and you will be able to browse it:

K2 - App Catalog creating App Catalog 4

4) Last touch šŸ™‚ Configure App URLs. Go to CA and click on Apps to get to Configure App URLs link:

K2 - App Catalog Configure App URLs 1

On the next page you have to specify App domain and App prefix and Ā click OK These settings will shape your apps URLs.

K2 - App Catalog Configure App URLs 2

This concludes App Catalog configuration and you can now test your App Catalog. As proverb puts it “The proof of pudding is in eating” and by extension we can say that “The proof of App Catalog is adding some app(s) into it”.