Windows 10: Set Display, Apps and websites language to English (United States) and keyboard to Belgian (Period)

June 14, 2018 at 9:25 am in Belgian (Period), Belgian beers, belgian chocolates, Belgium, ITPro, Keyboard shortcut, Keyboards, scugbe, Windows 10, Windows Apps, Windows Display Language by Wim Matthyssen

When you install and set up Windows 10, you’re asked to choose a default system language. Normally, you do not need to change the language after the initial setup but there might be some situations where you do. I ‘m a Belgian and working as an ITPro in that small country which has the best chocolates and beers, I like to have my Windows 10 display language and Windows Apps language set to English (United States) and my keyboard to Belgian period (Azerty).

However, when you deploy Windows 10, with country or region set to Belgium and system language set to English as a preferred language also Nederlands (België) is installed as first language for Apps and websites.

clip_image002

So even if your Windows display language is all set to English whenever you open a website or Windows App the language used is Dutch.

clip_image004

clip_image006

For me this is a little bit annoying. I know this can come in handy, if you’re bi-lingual and you type documents in Dutch, but also enter commands in Command Prompt in English, but for me that’s not the case. But if you prefer you can set the language on a per-app basis and then Windows will remember which language you prefer to use in that particular app. There is even a keyboard shortcut if you want to switch manually between two or more languages. Just press the Left Alt + Shift keys together to switch between languages on the fly.

To set my Windows display and Windows App (+ websites) language to English and set my keyboard to Belgian (Period) I followed the below steps.

Open All settings (or press the Windows key + I) to open the Windows Setttings page and then click Time & Language.

clip_image008

clip_image010

Select Region & language on the left.

clip_image012

At the Preferred languages topic, you can choose to set Nederlands (België) as the second language or choose to Remove this language. I choose to Remove this language completely (to be able to Remove a language you also need to set if first as the second language, otherwise you are not able to delete it).

clip_image014

clip_image016

If you Remove a first language you also need check and possible set your preferred keyboard language at the first language shown. To do so select the language and click Options.

clip_image018

Because English Unites States uses US (QWERTY), which I do not want to use. I first I need to add my second preferred keyboard. Press Add a keyboard and select the Belgian (Period) keyboard. When added you can remove the US (QWERTY) keyboard.

clip_image020

clip_image022

Now your all done. Like you can see the Windows display, website(s) and Windows App language are all set to English and I can type with my preferred Azerty keyboard settings.

clip_image024

clip_image026

clip_image028

Hope this comes in handy for the Belgium people. Till next time!

Wim Matthyssen (@wmatthyssen)

Azure Backup Server: Unprotected servers still showing up in the Azure portal even though their protection was stopped 3 months ago

June 11, 2018 at 9:49 am in Azure, Azure Backup, Azure Backup Server, Azure portal, Cloud, Cloud backup, MABS, MABS v2 by Wim Matthyssen

 

To help protect your hybrid backup setup with an Azure Backup Server (MABS), Microsoft introduced some security features built on three principals – Prevention, Alerting and Recovery. These features are enabled by default for newly create Recovery Services vaults, for existing vaults this link will show you how you can enable them. One of these features related to recovery will ensure you that Azure backup will retain all deleted backup data for 14 days, which ensures you can recover data using any old or recent recovery point(s).

clip_image002

Sometime ago I reconfigured a Protection Group which protected some Hyper-V VMs. Two Domain Controllers (DCs) were taken out of the Group and setup to only backup the C drive and the System State. On the MABS server all configuration went well and did not cause any specific issues or errors. However last week when I was checking the Recovery Services vault used to store the cloud backups,I noticed those two DCs were still showing up in the Backup items overview.

clip_image004

Like you can see, those two VMs are still there with no Disk or Cloud Recovery Points created after the protection was disabled.

clip_image006

To get the issue fixed, I followed some standard steps I always follow when having issues with a MABS. The first one is checking the current Azure Backup Agent version installed on the MABS, which was version 2.0.9109.0. Because there is a newer version available (at the time of writing version 2.0.9118.0), step one was getting that one in place.

clip_image008

To download the latest agent go to your Recovery Services vault blade in the Azure portal. Select Backup and on the Getting Started with Backup blade, select Backup goal. In the drop-down menu(s), select On-premises and Files and folders, click OK. In the Prepare Infrastructure blade, click Download Agent for Windows Server or Windows Client. Save MARSAgentInstaller.exe.

clip_image010

clip_image012

Install the latest agent on the MABS server. After the agent installation completes restart the following service:

Microsoft Azure Recovery Services Management Agent

clip_image014

clip_image016

clip_image018

Although the agent is now at the latest version it still did not fix the protection status of the deleted servers in the Azure portal.

After doing a little more troubleshooting (reading the logs, etc.) , I decided to open an Azure support ticket. The support agent who assisted me, told me, just like I already suspected, that this was currently  the default behavior from the azure backup service in some Azure regions (current backend design behavior like they say). The product team was already aware of this issue and they definitively will fix it in some later update.

If you cannot wait for the update, there is a quicker fix for the issue, you just need to delete the whole MABS server from the Azure portal and reconnect the server all over again. However, for me and even more for the customer this was a no go. So, we will wait for the proper backend update which will hopefully not take that long anymore.

Hope this helps whenever you face the same backup behavior in the Azure portal with your deleted MABS backups.

Wim Matthyssen (@wmatthyssen)

Azure Tip: Use Ctrl+Alt+D to check Azure Portal load times

May 7, 2018 at 6:55 pm in Azure, Azure portal, Azure Tip, Cloud, Keyboard shortcut by Wim Matthyssen

 

The Azure Portal is the go-to place to manage all of your Azure services in one hub. I myself spend a lot of time in the portal to build, deploy, modify and manage customers cloud resources. I am sure a lot of you do the same.

But sometimes this portal feels slow without any specific reason and then it is really difficult to find out why. Whenever that is the case there is a keyboard shortcut you can use to check the portal load time of all opened blades.

If you press the keyboard shortcut CTRL + ALT + D you can see the load time and other useful information for every title.

clip_image002

clip_image004

clip_image006

clip_image008

clip_image010

Pressing CTRL + ALT + D again will remove the portal load information.

Beside this useful keyboard shortcut there are some others you can use specifically for the Azure portal. You can open the Keyboard shortcut help item in the Help Menu on the top-right of the portal to see all of these shortcuts.

clip_image012

Hope it helps!

Wim Matthyssen (@wmatthyssen)

Creation of an Azure VPN gateway failed due to associated NSG

May 4, 2018 at 8:53 am in Azure, Cloud, GatewaySubnet, NSG, VNet, VPN gateway by Wim Matthyssen

 

A VPN gateway is a specific type of virtual network gateway that sends encrypted traffic between your virtual network (VNet) and your on-premises location across a public connection. You can also use a VPN gateway to send traffic between virtual networks across the Azure backbone.

While deploying such a gateway trough the Azure portal, the creation took a very long time and in the end the deployment Failed.

clip_image002

In the Activity log the following Error Code was showed.

OnlyTagsSupportedForPatch

clip_image004

clip_image006

After some troubleshooting and reviewing the complete VNet deployment, which was done through Azure PowerShell, I finally found out what caused the gateway deployment to fail.

An important remark is mentioned in the Microsoft technical documentation for creating a Site-to-Site connection in the Azure portal. It states that you may not associate a network security group (NSG) to the gateway subnet, which in my case was causing the issue.

clip_image008

The Azure PowerShell script used to setup the VNet and all of its Subnets also created NSGs for all subnets, the GatewaySubnet included.

To resolve the issue, I deleted the Failed gateway and set the Network security group for the GatewaySubnet to None.

clip_image010

clip_image012

Afterwards the creation of the gateway succeeded without any issues.

 

Conclusion

When you create a gateway subnet for your VNet you should never associated a NSG to it. This is not supported and the gateway will stop functioning as expected or completely fail. Always set the NSG to ‘None’. The gateway subnet also needs to be named ‘GatewaySubnet’ to work properly and never deploy any VMs or anything else to it.

Wim Matthyssen (@wmatthysen)

Azure Backup: Upgrade your Recovery Services Vault to enable support for large disk backups

April 5, 2018 at 6:59 am in Azure, Azure Backup, Cloud, Recovery Services vault by Wim Matthyssen

 

On March 13, 2018 the Azure Backup team announced the general availability for backup of Azure IaaS Virtual Machines (VMs) with large disks (1 to 4 TB), both managed and unmanaged. At the same time they released a set of other improvements to speed up the overall backup and restore process.

To enable these new features a one-time, one-directional upgrade must be done for every Azure Subscription where you wish to use these enhancements. Good to know is that this VM backup stack upgrade, can be started from any vault in your Subscription and will retain all your existing policies and recovery points.

 

Upgrade procedure

 

Open the Azure portal and login with you Azure credentials.

Go to your Recovery Services vault dashboard, on the top of the blade you will need to click the banner which says Support for > 1 TB disk VMs and improvements to backup and restore speed ->. If you do need see a banner, you can open Properties, go to VM backup stack and click Upgrade.

clip_image002

image

The Upgrade to new VM backup stack blade will open. Click on Upgrade.

clip_image004

The upgrade procedure will start, be aware that this process could take up to two hours.

clip_image006

Have fun backing up Azure VMs with these new enhancements. Till next time!

Wim Matthyssen (@wmatthyssen)

Windows Server 2019 (vNext) LTSC Preview – Build 17623 available for download

March 21, 2018 at 7:24 pm in Build 17623, Microsoft Tech Community, Windows Server 2019, Windows Server Insider, WS2019 by Wim Matthyssen

Yesterday Microsoft announced that Windows Server 2019 would be generally available in the second half of 2018, together with System Center 2019. As expected, this next-gen (vNext) Server OS is built on top of Windows Server 2016 and will focus on the following main areas: hybrid, security, application platform and hyper-converged infrastructures. Good to know is that Windows Server 2019 is a Long-Term Servicing Channel (LTSC) release, which means it will have 5 years of mainstream support and 5 years of extended support.

Whit this announcement Microsoft also released the first preview build (17623) of Windows Server 2019 LTSC to the public, which contains both the Desktop Experience as well as the Server Core edition in all 18-server languages.

To get started with the download of this Preview build, you need to be a member of Windows Server Insider program. If you are not yet registered for this Insider program, you can do so over here. Keep in mind that you can sign up with an organization or a personal account.

clip_image002

As a registered Insider, you can head over to the Windows Server Insider Preview download page. Under available Downloads you can now download the 4.2 GB ISO file. This build, which expires on 02/06/18, requires an activation key during setup. The following keys are allowed for unlimited activations:

  • Datacenter Edition 6XBNX-4JQGW-QX6QG-74P76-72V67
  • Standard Edition MFY9F-XBN2F-TYFMP-CCV49-RMYVH

clip_image004

clip_image006

clip_image008

When downloaded you can install the Windows Server 2019 OS from the ISO image on a virtual machine (VM) or on a physical server.

clip_image010

clip_image012

Have fun testing out this build and do not forget to provide your feedback to Microsoft using the Windows Feedback Hub app, or through the Windows Server space in the Microsoft Tech community.

Wim Matthyssen (@wmatthyssen)

Microsoft Wireless Display Adapter won’t connect with Windows 10 laptop running Hyper-V

March 1, 2018 at 8:35 pm in Client Hyper-V, Hyper-V, Microsoft Wireless Display Adapter, Miracast, Wi-Fi, Windows 10 by Wim Matthyssen

When delivering workshops at customers most of the time I use my Microsoft Wireless Display Adapter to show my presentations or demo’s on a big screen.

clip_image002

Normally, I only just need to plug in the USB and HDMI connectors from the Wireless Display Adapter to the HDTV, monitor or projector, and click Connect on the Windows 10 Action Center. My display adapter is then listed as on option and I only need to click on it to extend or duplicate my laptop screen. It is so easy and connecting with a Windows 10 device could not be quicker.

clip_image004

However last week while preparing a new Azure workshop, making a connection to my home TV did not go that smooth as usual. When I tried to connect to my display adapter, making a connection took a long time and at the end the message “Couldn’t connect” popped up while the TV was still showing Connecting.

 

clip_image006

clip_image008

After troubleshooting for some time and checking the usual steps (check adapter’s firmware, check Windows Updates, reset the adapter …) I finally figured it out. When making a connection the Wireless Display Adapter uses Miracast, a wireless technology, which makes communication between devices possible on either the 2.4 GHz or 5 GHz wireless frequency bands. The display adapter itself, even if it looks like a sort of HDMI to USB cable, has a full Wi-Fi card and antenna on board which it uses to connect to the wireless adapter on your laptop.

That is where my connection problem was situated. I do a lot of research on my laptop with the use of Client Hyper-V, which enables me to run all sorts of virtual machines (VMs) for testing purposes. For connecting some of those VMs to the Internet, I make use of an internal virtual switch, which uses a shared connection (Internet Connection Sharing) on my wireless adapter.

clip_image010

clip_image012

However, this Windows service causes some changes in the way the wireless adapter works, which in normal circumstances does not disturb anything, except when you try to connect to a Wireless Display Adapter.

So, after removing this sharing option, the Wireless Display Adapter connected as easily as before.

clip_image014

clip_image016

clip_image018

Conclusion

A Microsoft Wireless Display Adapter strongly depends on the wireless adapter in your device to setup communication. Any issues or changes to the wireless adapter in any way can cause connecting problems. If you still want to use Client Hyper-V on your Windows 10 laptop and connect your VM to the Internet with the use of your wireless adapter, I suggest to create an External virtual switch which connects to it. Do not forget to allow the management Operating System to share the wireless network adapter. This setup does not seem to disturb the connection with a Wireless Display Adapter.

Client Hyper-V: Unable to start a VM from saved state (Event ID 3326)

February 26, 2018 at 8:56 am in Client Hyper-V, Event ID 3326, Hyper-V, saved state, virtual machine by Wim Matthyssen

 

Last week while starting a virtual machine (VM) from saved state on my Windows 10 laptop with Client Hyper-V the following error popped up and the VM itself did not power on.

clip_image002

The error itself did not explain a lot why the startup from saved state was failing, but in the Hyper-V event logs (Event Viewer – Applications and Services Logs – Microsoft – Windows – Hyper-V-Worker – Admin) Event 3326 was shown which showed a lot more:

The Virtual Machine ‘VM-W8-HOME’ failed to start because there is not enough disk space. The system was unable to create the memory contents file on ‘C:\_VM\VM-W8-HOME\Virtual Machines\CB9D8995-F1FC-4349-9C35-7728F5B90245′ with the size of 7340 MB. Set the path to a disk with more storage space or delete unnecessary files from the disk and try again. (Virtual machine ID CB9D8995-F1FC-4349-9C35-7728F5B90245)

clip_image004

The error indicates that not enough free space is available on the host which causes problems to start the VM. The View in Disk Management (tap the Windows key + R to open Run, type diskmgmt.msc in the empty box and tap OK) indeed shows that the C: drive only has 2 % free, which is not sufficient to start the VM.

clip_image006

After determining that the error was caused by a lack of disk space, I cleaned up my C: drive by deleting some unnecessary and temporary files to free up some more space (at least 4096 MB which equals the amount of virtual memory of the VM). As a result, the VM started up again.

clip_image008

Conclusion

To start a VM from saved stated the amount of free disk space should at least equals the amount of virtual memory allocated to the VM. For example, if your VM has 4096 MB of virtual memory assigned, you should have at least 4096 MB available on the drive. If you do not have enough disk space available you should free up some space to be able to start the VM. As a recommendation you should always keep at least 10 – 20 % of free disk space available.

Azure Backup Server: SQL 2016 AlwaysOn protection fails with Internal error code 0x80990F75

January 23, 2018 at 3:54 pm in 0x80990F75, Azure, Azure Backup, Azure Backup Server, Microsoft Azure Backup Server, Microsoft Azure Backup Server v2, SQL Always On Availability Groups, SQL Server 2016 by Wim Matthyssen

While setting up a new backup job to protect a SQL Server 2016 AlwaysOn Availability Group (AG) using Azure Backup Server (MABS), the job failed and ended up with the Protection Status – Replica is inconsistent.

clip_image002

Because this status does not say a lot about what exactly went wrong, I looked up the Critical alert under the Monitoring tab. There the following more detailed message was shown:

The DPM job failed for SQL Server 2016 database <DBname> on <serverName > because the SQL Server instance refused a connection to the protection agent. (ID 30172 Details: Internal error code: 0x80990F75)

clip_image004

This issue occurs because when you create a new Availability Group by default, the location where backups should occur is set to Prefer Secondary and the setting Make Readable Secondary is set to No, which always results in MABS getting the above error.

clip_image006

To resolve the issue, open SQL Management Studio and connect to server instance that hosts the primary replica. Expand the Always On High Availability node and the Availability Groups node. Click the availability group whose replica you want to change and expand Availability Replicas.

clip_image008

Right-click the Availability Replica, and click Properties (be sure to repeat this steps for all Availability Replicas you want to backup with MABS).

clip_image010

In the Availability Replica Properties dialog box, set the value of the field Readable secondary to Yes. Click OK to save the new setting.

clip_image012

When you now run the Perform consistency check … job on the failed Protected member in the MABS console, the status should end up in OK.

If not, and the status still ends up in Replica is inconsistent, be sure to check out my previous blog post http://scug.be/wim/2017/06/19/microsoft-azure-backup-server-unable-to-configure-protection-for-a-sql-database-id-3170-and-33424/ to see if the user NT Authority\SYSTEM has sysadmin rights on the SQL Server instance(s).

If on the other hand the status ends up in Online recovery point creation failed, just right-click the Protected member again and select Resume azure backups…

I hope this helps and if you have any questions feel free to contact my through my Twitter handle.

Wim Matthyssen (@wmatthyssen)

Azure Backup Server: Remove Unprotected computers with protection agent installed

January 4, 2018 at 8:36 am in Azure Backup Server, MABS, MABS v2, Microsoft Azure Backup Server, Microsoft Azure Backup Server v2, PowerShell by Wim Matthyssen

While doing maintenance on a customer’s Azure Backup Server (MABS), I was unable to remove some unprotected computers in the MABS console. The Remove resulted in a fail and the error page didn’t show a direct reason why this occurred.

clip_image002

clip_image004

clip_image006

clip_image008

But no worries, this is where PowerShell came into the rescue to force the removal of the broken agent from the DPMDB database. Take notice that this solution will not uninstall the protection agent from the (un)protected computer. When required, you still need to uninstall that agent manually.

Open the DPM Management Shell and run the following command, it will prompt you for the rest of the parameters one at a time (always use the FQDN name for both parameters).

You can also run this command with all paramaters already filled in. Just replace [DPMServerName] with the name of the MABS server and [ProtectedComputerName] with the name of the (un)protected computer that must be removed.

image

Like you can see the agent(s) are now removed from the MABS console.

clip_image012

Hope it helps.

Wim Matthyssen (@wmatthyssen)