Search This Blog

Tuesday, January 29, 2019

Tuesday, January 22, 2019

(FIXED) Office 365 ProPlus apps do not start, error "The application was unable to start correctly (0xc0000361)"

Most of the companies already have implemented or at least are considering some application whitelisting solution. In Microsoft world if you cannot afford Windows Enterprise then Software Restriction Policies (SRP) is a good alternative.

If you implement SRP and use Office 365 ProPlus, then there there is a good chance that you will get error "The application was unable to start correctly (0xc0000361)" for Office apps after implementing SRPs.


To solve this you have to change configuration in SRP - in enforcement options you will need to select to apply SRPs to all software files except DLLs


After this change and group policy update and reboot on client side, Office apps will start correctly.



Saturday, January 19, 2019

Static Public IP addresses can now be configured for Azure VPN Gateways

A while a ago it was not possible to use static public IP addresses for Azure Virtual Network Gateways. It meant to two things:

  • Gateway address would not actually change if it was not deleted
  • If gateway was deleted and recreated, then you would need to use different public IP address
The second scenario could happen if, for example, you needed to change gateway type from Policy-based to Route-based.

Now there is an option to use static public IP addresses for Azure VNET Gateways.


This option is available for new VpnGw1AZ, VpnGw2AZ and VpnGw3AZ SKUs.

FIXED: Cannot connect to Azure with Point-to-Site VPN, Error 0x800704c9

As a part of setting up an Azure environment, I enabled Point-to-Site VPN for the Virtual Network Gateway. I had this done previously so I though this will going to an easy process.

So, configured certificate authentication, downloaded VPN client, installed it, but upon connecting I got error 0x800704c9, the whole error text was "The remote computer refused the network connection. (Error 0x800704c9)".


I clicked properties, viewed the log file but it didn't help too much.
Then I tried connecting to the port 443 (as I had SSTP VPN) to virtual network gateway and the connection was successful. 
Finally, I had the magic idea to connect from different computer, and this did the trick. The problems I was experiencing were on Windows 7 and they were gone when connecting from Windows 10 v1803 machine.

Thursday, January 17, 2019

Do NOT install latest ASR Provider (5.1.3900.0) on SCVMM 2016

I would advise not to install latest Azure Site Recovery Provider version (5.1.3900.0) on SCVMM 2016 servers.

This is how it went for me.
At first, in Azure Portal I saw that an update was available for ASR Provider. As this previously had not caused any issues I downloaded and wanted to install.

But it didn't go so good this time. SCVMM service stopped during install as usual, but after ASR Provider install finished, it didn't start.
When trying to start it manually I got message:

"The System Center Virtual Machine Manager Service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs"

C:\ProgramData\ASRLogs and C:\ProgramData\VMMLogs didn't say anything useful.
So after some time of unsuccessfull troubleshooting I uninstalled ASR Provider and boom - the SCVMM service started successfully.

Installed ASR Provider v5.1.3900.0, again SCVMM service couldn't start.

So I installed previous ASR Provider version (5.1.3800.0) and everything works as it should.

I will wait for next ASR Provider release obviously :)


Windows Server 2012 R2 Mainstream support has ended

Today I had a call with Microsoft Support about an issue with Windows Server 2012 R2, almost instantly I got response that Windows Server 2012 R2 mainstream support has ended and they won't be able to help.

It turns out that mainstream support for Windows Server 2012 R2 ended in October 2018.

Time passes by so quickly :)

Tuesday, January 15, 2019

(Solved) Domain controller blue screens with error 0xc00002e2

In a infrastructure consolidation project I had to move domain controller from one Windows Server 2012 R2 Hyper-V host to another.

I thought that this will gonna be an easy task.. but it wasn't.

We shut down the VM, exported it and imported in destination Hyper-V host. This is where fun began. The domain controller didn't boot up and bluescreened with error 0xc00002e2.



Some blogs on internet said that probably there are problems AD database, and it needs to be repaired.

In my case the situation was a bit easier. This is what we did:

  1. Booted up the DC in DSRM - Directory Services Restore Mode. Yes, you will need DRSM password for this.
  2. Found out that D: disk was not available (this was the disk where AD database was residing)
  3. Went to Disk Management and found that D: disk is offline
  4. Brought the disk online
  5. Restarted the domain controller and it started up successfully.
The bottom line is that error 0xc00002e2 on domain controller indicates that there are problems with AD database.


Monday, January 14, 2019

Cloudyn activation error "The specified API key is not a top level enrollment key" solved

Cloudyn or Azure Cost Management is a tool which helps to analyze Azure costs.
Usually activating it is pretty easy - just go to Azure portal, select "Cost Management + Billing", select Cloudyn and click "Go to Cloudyn"









If you are using Azure Enterprise subscription, then you need API Access Key which can be generated from ea.azure.com portal.

Once you have it, enter it during Cloudyn activation.

If you receive "The specified API key is not a top level enrollment key" during activation, then it means that the account which was used to generate API Access Key does not have full admin permissions in ea.azure.com portal.

If there is an Enrollment section in ea.azure.com portal, then it means you have full admin there.

Saturday, January 12, 2019

Hyper-V Live Migration does not work, how to fix error 0x8007052E

If you have a Hyper-V cluster and Live Migration does not work and you are receiving error "Failed to register cluster name in the local user groups: The user name or password is incorrect. (0x8007052E). Hyper-V will retry the operation." in Hyper-V-High-Availability event log, then most likely you will need to reset Failover Cluster AD account password (sometimes als called CNO - Cluster Name Object).



To reset CNO password:

  1. Open Failover Cluster console.
  2. In the left pane click Cluster Name
  3. In the "Cluster Core Resources" section select server name resource, right-click it and select Take Offline. VMs will not stop.
  4. The on server name resource choose More Actions -> Repair, this will reset CNO password
  5. Bring online server name resource.
Live Migration should work again now.

While troubleshooting the problem you can generate cluster log with Get-ClusterLog Powershell command, which will generate a text based log file C:\Windows\Cluster\Reports\cluster.log.
During live migration we would see there that CLUSTERNAME$ account cannot authentication because of wrong password.