Category Archives: Windows Server

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.

Windows Server 2016: CDPUserSvc has stopped working

You may observe the following error on Windows Server 2016 immediately after OS startup:

CDPUUserSvc_65df7 has stopped working

This “has stopped working” part tells us that some unhandled exception occurred, so we can switch over to Event Viewer to find some more details about it:

svchost.exe_CDPUserSvc_65df7 – Exception code: 0xc0000005

Exception details are the following:

Faulting application name: svchost.exe_CDPUserSvc_65df7, version: 10.0.14393.0, time stamp: 0x57899b1c
Faulting module name: cdp.dll, version: 10.0.14393.1715, time stamp: 0x59b0d38c
Exception code: 0xc0000005
Fault offset: 0x0000000000193cf5
Faulting process id: 0x1b14

After quick research I found out that this error was introduced with some Microsoft updates and to resolve it on Windows Server 2016 14393.1884 you just need to apply another update 🙂 More specifically you need to install KB4053579, which can be downloaded from Windows Update Catalog. Applying this update resolves this error.

GAC folders

I keep forgetting exact GAC folders’ locations and whenever I try to Google this information it is always buried under some layers of misunderstanding and confused discussions. This steams from the fact that there are different locations depending on .NET version and bitness of your assemblies. So I’m just jotting down all the locations here for quick reference:

.NET 2.0 GAC:  C:\Windows\assembly

.NET 4.0 GAC: C:\Windows\Microsoft.NET\assembly

Now each of this folder has the following sub-folders:

GAC_32 for 32-bit assemblies (defines word size)

GAC_64 for 64-bit assemblies  (defines word size)

GAC_MSIL for assemblies that can be run in either 32-bit or 64-bit mode which are JIT compiled to the required word size as needed

On machines with x86/32-bit version of Windows (which is way too rare now, especially for Windows Server) there is only GAC_32 subfolder, and on x64 OS machines there are both GAC_32 and GAC_64 folders as 32-bit code is supported via emulation (WOW32).

Configuring Windows Server 2016 Core Domain Controller

In Windows Server 2016 you no longer have an opportunity to switch back and forth between core and GUI installation, hence you cannot do install and configure AD DS in a lazy way (using full GUI) and then convert it to core. That was something I discovered hard way long time ago – so I already have separate VHDX templates for Server 2016 core and full GUI VMs.

But it has been quite a while since I was playing with Server Core so when I starting provisioning my new Server 2016 core domain controller VMs today I realized that I need to remember quite a few commands to fully install AD DS on Server Core. I was about to create a blog post listing essential commands, but actually found very well written blog post on TechNet covering exactly that: Chad’s Quick Notes – Installing a Domain Controller with Server 2016 Core. So just sharing it here, instead of writing the same myself 🙂

Getting Hyper-V guest OS information without logging in to guest OS/VM

The other day it was necessary for me to confirm Windows OS build in  Hyper-V guest VM without logging in into it. I simply received VM from the client but no credentials which I could use, but it was necessary to quickly confirm guest OS build. I was certain that there is a way to query such data from Hyper-V host without logging into guest and with no credentials. After some googling I was not able to find some simple command or one liner to pull this data (opening PS session into VM was not an option as it requires credentials), but I’ve found good function which does exactly what I need on Yusuf Öztürk blog, here it is:

Once you have this function, you can use it like this:

Get-VMGuestInfo VMNAME -HyperVHost HyperVHostName

Sample output from this function: