How to use your Surface Go as secondary screen for any other Surface device

July 4, 2019 at 1:13 pm in HDMI over Wi-Fi, Miracast, second screen, Surface, Surface Go, Surface Laptop, Windows 10 by Wim Matthyssen

At home or in the office I always use at least two screens. This significantly improves my multitasking experience and productivity when working with several apps or applications. So that when I need to take some screenshots or just when I am reading technical documentation while doing research, I do not always need to switch between all the different tabs (Windows + Tab key) to open a specific app or application.

clip_image002

When working remotely I most of the time use my Surface laptop, which works like a charm most of the time, but working on one screen isn’t that convenient when writing technical documentation or a new blog post.

Because carrying and extra monitor with me in my laptop bag is not really an option , these days I use my Surface Go (also works with any other Surface or Windows 10 device) as my secondary screen without the need for any third-party software due the Miracast built-in feature in Windows 10. Thanks Peter De Tender (@pdtit) for the great tip!

Miracast is a standard for wireless connections which allows users to wirelessly share multimedia (seamless display), including high-resolution pictures and high-definition (HD) video content between Wi-Fi devices which support Miracast, even if a Wi-Fi network is not available. It was introduced in 2012 by the Wi-Fi Alliance and it can roughly be described as HDMI over Wi-Fi, replacing the cable from the device to the display.”

Configuration

On the Surface device, in my case my Surface Go, which you want to use as a secondary screen, click on the Action Center icon on the lower right side of your taskbar and then click the All Settings tile to open Settings.

clip_image004

Click on System.

clip_image006

On the left column, select Projecting to this PC. Then configure it as you prefer. For example you can set it up to require a PIN for pairing.

clip_image008

Go to your primary device, in my case my Surface laptop and click on the Action Center icon and select Project, or simply press the Windows + P key.

clip_image010

Select Extend (or Duplicate) and at the bottom click on Connect to a Wireless Display. On the CONNECT page select the other Surface device (for me my Surface Go).

clip_image012

clip_image014

Now a Connect blade will popup on your secondary Surface device (Surface Go). Select your preferred setting (Always allow or Allow Once) and click on OK.

clip_image016

If you have configured to use a PIN, the PIN will be shown on the secondary Surface. You now need to type in this PIN in on the primary Surface before clicking on Connect.

clip_image018

If all goes well, you should now have your secondary Surface connected as an extended (Connected – Extend) screen.

clip_image020

clip_image022

clip_image024

That’s all it takes to use your second Surface as an extra screen. I always use two Surface devices, but like already said before, this should also work for any other Windows 10 devices. I hope you will give it a try.

Wim Matthyssen (@wmatthyssen)

Install the Azure Portal app (Preview) to manage your Azure resources

May 8, 2019 at 4:04 pm in Azure, Azure Management, Azure Portal app, Cloud, Preview by Wim Matthyssen

In addition to the Azure Portal and the Azure mobile app, there is now another option available to access and manage all your Azure resources, namely the Azure Portal app. Although it is still in preview, it already gives you the same experience as the Azure Portal, without the need of a browser, like Microsoft Edge or Google Chrome.

This comes in handy, when for example you want to connect to the Azure Portal f from any kind of “Management server” or from a Windows client which has restrictions to use any kind of browser.

To get started you first need to browse to https://preview.portal.azure.com/app/Download and click on the Download the Azure Portal app button to start the download.

clip_image002

clip_image004

Once downloaded you need to run the AzurePortalInstaller.exe file.

clip_image006

Once installed you can now open the Azure Portal app from your Windows 10 Start menu or by opening the search icon on the taskbar and looking for azure.

clip_image008clip_image010

You need to sign in with your Azure account and when you have done that you can start using the app for managing all your Azure resources just like you are used to with the Azure Portal.

clip_image012

clip_image014

image

clip_image018

Hope you enjoy this new app, I already do.

Wim Matthyssen (@wmatthyssen)

Unable to connect Hotmail account in Outlook 2019 after enabling two-step verification

May 6, 2019 at 1:43 pm in App Password, Microsoft Authenticator, Outlook, Outlook 2019, two-step verification by Wim Matthyssen

After enabling two-step verification for my Microsoft account, I was unable to connect Outlook 2019 with my Hotmail (Outlook.com) account and I was repeatedly being prompted for my password. Although the filled in password was correct, I always received an “incorrect password” error.

clip_image002

After doing some research I found out that some apps, like Outlook (Desktop or Mobile) and other mail apps which use the EAS protocol, require an app password when two-step verification is configured.

I followed the below steps to get the required App Password for Outlook and to get my Hotmail account configured in Outlook 2019.

 

Get an App Password and configure your Hotmail or Outlook.com account in Outlook 2019

Log on to the Microsoft Account Management website with your credentials and click on Security.

clip_image004

On the Security basics page click on the more security options link. Log in with your credentials if asked.

clip_image006

On the Additional security options page, under the App passwords header, click on Create a new app password.

clip_image008

Use the generated password (copy and paste) which is being displayed to log on to your Hotmail or Outlook.com account from Outlook.

image

clip_image012

* Don’t forget to mark Remember my credentials.

Your account should get configured successfully now.

clip_image014

Hope this helps!

Wim Matthyssen (@wmatthyssen)

Hyper-V: Automatic Virtual Machine Activation

March 8, 2019 at 8:25 am in Automatic Virtual Machine Activation, AVMA, Hyper-V, PowerShell, PowerShell Direct, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019 by Wim Matthyssen

 

With the release of Windows Server 2012 R2 back in 2013, Microsoft introduced a feature called Automatic Virtual Machine Activation (AVMA). AVMA handles the activation process of any of your Hyper-V virtual machines (VMs) running on a physical Hyper-V host which is properly licensed with a Windows Server Datacenter license. In this way you do not have to deal with managing the product keys for each individual VM.

The VM activation process, which binds the VMs activation to the licensed Hyper-V host, takes place during the startup process of the VM. Because the activation takes place between the VM and the Hyper-V host it resides on, you are even able to license VMs in completely isolated environments or remote locations without any Internet connection. When the guest OS is activated, it only rechecks its activation against the host until the next VM reboot, or after 7 days.

 

Requirements for AVMA

  • A Hyper-V host running a Datacenter Edition of Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019. Keep in mind that if you migrate an AVMA licensed VM to a Hyper-V host which is not licensed with a Windows Server Datacenter license, the VM will become unlicensed. In this case you should replace the AVMA key in the VM with another valid non AVMA license key.
  • The Hyper-V Data Exchange Service (KVP), which is part of the Integration Services must be enabled on the VM.
  • In the VM itself the Microsoft Hyper-V Activation Component Driver should have an enabled device status and should be working properly.
  • AVMA does not work with other Virtualization Server technologies.

 

Supported Guest Operating Systems for AVMA

Only Windows Server guests are covered by AVMA. The below table shows which guests can be activated by each different Hyper-V host version. All server editions (Datacenter, Standard or Essentials) installed with Desktop Experience or Server Core can be activated.

clip_image002

*AVMA in Windows Server 2019 can also activate Windows Server version 1809, 1803 and 1709.

 

AVMA Keys

The following keys can be used to activated the specific guest operating system of a VM.

Windows Server 2019

clip_image004

Windows Server version 1809

clip_image006

Windows Server version 1803 and 1709

clip_image008

Windows Server 2016

clip_image010

Windows Server 2012 R2

clip_image012

 

Configure AVMA

1) First of all, you should verify that the Data Exchange option is enabled in the Integration Services for the VM.  To ensure this open Hyper-V Manager and right-click the VM and click on Settings…

clip_image014

2) On the Settings Windows, under Management select Integration Services and verify that Data Exchange is marked.

clip_image016

You can also use PowerShell to see if the Data Exchange service is enabled. To get a list of the running Integration Services of a VM, run the following command (replace the VM name by your own) in a PowerShell window (as Administrator) on the Hyper-V host hosting the VM:

clip_image018

To turn on the “Key-Value Pair Exchange” service when it is disabled you need to run the following command:

clip_image020

3) To install an AVMA key in a VM (in my example for a Windows Server 2019 VM), run the following command in a PowerShell window (as Administrator) on the VM.

clip_image022

*The AVMA key can also be provided during an Unattended setup using a unattend.exe setup file. In this way the key is already injected during the build phase of that particular VM.

You can also use PowerShell Direct from the Hyper-V host to activated a specific AVMA key for a VM running on the host. Open a PowerShell window (as Administrator) on the Hyper-V host and run following command:

clip_image024

clip_image026

4) You can verify the correct installation of the AVMA key, by opening All settings – Update & Security – Activation in the VM.

clip_image028

4) You can also verify the VM’s AVMA activation status on the Hyper-V host by opening the Event Viewer and searching for Event ID 12310.

clip_image030

clip_image032

clip_image034

clip_image036

I hope this blog post did learn you something about AVMA and that this feature eases your VM activation process. If you have any questions, always feel free to contact me through my twitter handle.

Wim Matthyssen (@wmatthyssen).

Azure PowerShell Error: “Your Azure credentials have not been set up or have expired, please run Connect-AzureRmAccount to set up your Azure credentials”

February 27, 2019 at 6:28 pm in Azure, Azure credentials, Azure PowerShell by Wim Matthyssen

While working on a new Azure IaaS deployment for a customer, I encountered the following error when running several Azure PowerShell cmdlets.

“Your Azure credentials have not been set up or have expired, please run Connect-AzureRmAccount to set up your Azure credentials”

clip_image002

Running the Connect-AzureRmAccount command for several times, like proposed in the error message, did not solve the problem. Neither did opening a new PowerShell window or even completely restarting my Surface laptop.

clip_image004

I finally got it fixed by running the Remove-AzureRmAccount cmdlet, which removes all credentials and contexts (subscription and tenant information) associated with that specific Azure account.

clip_image006

After executing the Remove-AzureRmccount cmdlet , and after login in again using the Login-AzureRmAccount cmdletall other cmdlets ran again like they should.

clip_image008

clip_image010

Hope this helps!

Wim Matthyssen (@wmatthyssen)

PowerShell: AzCopy download and silent installation

February 22, 2019 at 10:52 am in AzCopy, Azure, Download, PowerShell, PowerShell Script, Silent installation by Wim Matthyssen

AzCopy is a free command-line tool that is offered by Microsoft. It allows you to easily copy and transfer data (data migration) from and to Azure storage. It is designed for high performance transfers and can be deployed on both Windows and Linux systems (separate versions). AzCopy for example allows users to copy data between a file system and a storage account, or between storage accounts. Users have the possibility to select items by specifying patterns, like wildcards or prefixes, to identify the needed files for upload or download. It currently supports Microsoft Azure Blob, File and Table storage.

To automate the download and silent installation process of this useful tool, I wrote the below PowerShell script which does all of the following:

  • Create a Temp folder on the C: drive if not already available.
  • Create an AzCopy download folder in C:\Temp if not already available.
  • Download the latest Azcopy .msi (Windows) file.
  • Install AzCopy silently without any user interaction.
  • Delete the .msi file after installation.
  • Remove the AzCopy folder.
  • Exit the PowerShell window.

 PowerShell script

clip_image002

clip_image004

clip_image006

clip_image008

If you prefer you can download the complete script from the TechNet gallery.

More information and how to use AzCopy you can find over here.

This concludes this blog post, have fun using AzCopy for moving or copying data to or between storage accounts.

Wim Matthyssen (@wmatthyssen)

PowerShell – BGInfo Automation script for Windows Server 2019

January 23, 2019 at 8:04 pm in BgInfo, Hyper-V, PowerShell, PowerShell Script, Sysinternals, VM Template, Windows Server 2019, WS2019 by Wim Matthyssen

Probably everyone knows the Sysinternals tool BGInfo (currently version 4.26). For those who don’t, it’s a great free tool from Microsoft which captures system information form a workstation or server (probably where it is the most useful) and displays that relevant data directly on the desktop of that particular machine. It can show useful information like, DNS settings, used IP Addresses, computer name, domain name, OS version, memory, service pack version, etc.

image

Whenever I create a new Windows Server 2019 Virtual Machine (VM) template for customers, I mostly add this tool in the base image (also called golden image) and set it so it starts up automatically whenever a user logs on to the server. To automate this process, I wrote a PowerShell script which automates the complete BGInfo installation and configuration.

This script will do all of the following:

  • Create the BGInfo folder on the C: drive if the folder does not already exist.
  • Download the latest BGInfo tool from the Sysinternals webpage.
  • Extract and cleanup the BGInfo.zip file in the BGInfo folder.
  • Download the logon.bgi file which holds the preferred settings.
  • Extract and cleanup the LogonBgi.zip file in the BGInfo folder.
  • Create the registry key (regkey) to AutoStart the BGInfo tool in combination with the logon.bgi config file.
  • Start BGInfo for the first time.
  • Exit the PowerShell window upon completion.

 

Prerequisites

  • Windows PowerShell 5.1
  • Run PowerShell as Administrator

 

PowerShell script

To use the script copy and save the above as BGInfo_Automated_Windows_Server_2019.ps1 or download it from the TechNet Gallery. Afterwards run the script with Administrator privileges from the server you wish to use for your VM template.

image

image

image

image

image

image

If you want to change any configuration setting (for example the font style or published info), just open the logon.bgi file and adjust the settings to your preferences. Click OK to save and set the new settings.

image

image

Hope this script comes in handy for you. If you have and questions or recommendations about it, feel free to contact me through my Twitter handle.

Wim Matthyssen (@wmatthyssen)

Hyper-V 2019: Configure antivirus exclusions in Windows Defender Antivirus

January 9, 2019 at 3:43 pm in antivirus exclusions, automatic exclusions, custom exclusions, Hyper-V, PowerShell, Windows Defender Antivirus, Windows Server, Windows Server 2019, Windows Server 2019 Hyper-V, WS2019 by Wim Matthyssen

Running a solid, constantly updated antivirus product on your Hyper-V hosts is a necessity to keep a healthy and secure virtual environment. By using Windows Defender Antivirus, the built-in antimalware solution in Windows Server 2019 you will be provided with next-gen cloud-delivered protection, which includes near-instant detection, always-on scanning and dedicated protection updates.

However, when using any antivirus software on a Hyper-V host, you also risk having issues when it is not configured properly and especially when real-time scanning (or monitoring) is enabled. This can negatively affect the overall host performance and even cause corruption of your virtual machines (VMs) or Hyper-V files.

To avoid these file conflicts and to minimize performance degradations you should implement the following recommend antivirus exclusions (directories, files and processes) on all your Hyper-V hosts, which can be found over here.

Luckily Windows Defender Antivirus automatically enrolls certain exclusions (automatic exclusions), defined by your specific server role. To determine which roles are installed on the server, Windows Defender Antivirus uses the Deployment Image Servicing and Management (DISM) tools. You should be aware that these automatic exclusions will not appear in the standard exclusion list shown in the Windows Security app.

clip_image002

Below you can find a list of the automatic exclusions for the Hyper-V role:

File type exclusions:

  • *.vhd,*.vhdx,*.avhd,*.avhdx,*.vsv,*.iso,*.rct,*.vmcx,*.vmrs

Folder exclusions:

  • %ProgramData%\Microsoft\Windows\Hyper-V
  • %ProgramFiles%\Hyper-V
  • %SystemDrive%\ProgramData\Microsoft\Windows\Hyper-V\Snapshots
  • %Public%\Documents\Hyper-V\Virtual Hard Disks

Process exclusions:

  • %systemroot%\System32\Vmms.exe
  • %systemroot%\System32\Vmwp.exe

Hyper-V Failover Cluster folder exclusions:

  • %SystemDrive%\ClusterStorage

Although the automatic exclusions include almost all recommended Hyper-V antivirus exclusions you still may need to configure additional custom exclusions. These custom exclusions will take precedence over the automatic exclusions but will not conflict if a duplicate exists.

If you prefer to disable automatic exclusions you can run the following PowerShell cmdlet.

Below you can find an additional short list of custom exclusions for a server running the Hyper-V role which you can implement if applicable to your environment. There can be even more exclusions for your specific environment.

  • Any custom virtual machine configuration or hard disk drive directories (for example E:\VMs).

clip_image004

  • Any custom replication data directories, if you’re using Hyper-V Replica.
  • The Vmsp.exe process (%systemroot%\System32\Vmsp.exe)

clip_image006

  • The Vmcompute.exe process (%systemroot%\System32\Vmcompute.exe).

clip_image008

To add these exclusions for Windows Defender Antivirus in the Windows Security app you can follow the below steps.

Open the Windows Security app by clicking the magnifier in the task bar and type defender. Select Virus & threat protection.

clip_image010

Under the Virus & threat protection settings title select Manage settings.

clip_image012

On the Virus & threat protection settings page scroll down to Exclusions setting and click on Add or remove exclusions.

clip_image014

Click Add an exclusion. Click the + icon to choose the type and set the options for each exclusion. When adding an exclusion click Yes if the User Account Control box pops up.

clip_image016

clip_image018

When all custom exclusions are added the screen will look like this.

clip_image020

To remove an added exclusion, press the down arrow next to the exclusion and click Remove.

clip_image022

You can also add these custom exclusions with the use of PowerShell (as administrator). To do so you need to run the below commands.

clip_image024

Hope this helps securing your Hyper-V hosts.

Wim Matthyssen (@wmatthyssen)

Create an Azure Monitor action group with Azure PowerShell

December 27, 2018 at 12:40 pm in action groups, automation, Azure, Azure Monitor, Azure PowerShell, beemug by Wim Matthyssen

Azure Monitor, Microsoft’s built-in monitoring service, allows you to monitor and gain more visibility into the state of your resources from a single place in the Azure portal, to help you quickly find and fix problems.

To notify users that an alert has been triggered, Azure Monitor (and also Service Health alerts) uses action groups. This feature allows an owner of an Azure subscription to group a collection of actions to take when an alert is triggered. Owners can create an action group with functions such as sending an email or SMS, as well as calling a webhook and re-use it across multiple alerts. Action groups can be created through the Azure portal, but to automate the process you can also use Azure PowerShell.

In the below example a new action group, called email-ag, is created. To use the script, copy it and adjust it for your own purpose. Save it as .ps1.

clip_image002

You can check all existing action groups in your subscription, by running the below cmdlet. In my example the previously created action group email-ag is shown.

clip_image004

Like earlier said, you can also Add, validate or manage action groups through the Azure portal by opening Monitor, selecting Alerts and selecting Manage action groups. For more information you can check out the documentation page.

clip_image006

clip_image008

Hope the script comes in handy!

Wim Matthyssen (@wmatthyssen)

Azure: Unable to connect to VMs in a peered VNet from P2S VPN

October 11, 2018 at 8:50 am in Azure, Azure Networking, Azure virtual network, P2S client, P2S VPN, RDP, VNet peering by Wim Matthyssen

These days when setting up a greenfield Azure IaaS environment for customers, we use the hub-spoke network topology with shared services. In this topology the HUB network is used as central point of connectivity and a place to host services that can be consumed by the different workloads hosted in the spoke VNets. All spokes are peered with this Hub network, to isolate all workloads. Whenever I work remotely on these environments, I mostly use a Point-to-Site (P2S) connection to securely connect to the different VNets from my client devices.

However last week while deploying a new environment for a customer, I stumbled upon a problem where I couldn’t RDP (private IP addresses) to the virtual machines (VMs) in the different spokes. The RDP access to the VM’s in the Hub VNet worked without any issues.

clip_image002

This is caused, because by design the P2S client will have routes listed for all VMs in the HUB VNet (which hosts the Virtual Network Gateway). However, even though the HUB VNet and the other VNets are connecting via peering, the P2S client will not have any routes presented in its configuration to discover the VMs in the other VNets. In order for the P2S client to be able to reach all VMs (trough for example RDP) located in the peered VNets, a static route for these VNets should be added in the routes.txt file of that specific connection. You can follow the steps below to get this working.

Solution

Open Run, type %appdata% and press Enter.

clip_image004

Open Microsoft – Network – Connections – Cm and select the right connection folder. Next, open the routes.txt file in Notepad (to open just double-click).

clip_image006

Remark

You can also find the correct path to the routes.txt file in the P2S VPN log file. You can open this file by opening your P2S connection and selecting on Properties instead of Connect. In the opened Properties page select View Log. Search for ActionPath, which will show you the location of the file.

clip_image008

clip_image010

End of remark.

In the opened routes.txt file, add the static routes for the other VNets.

For example:

ADD 10.6.0.0 MASK 255.255.240.0 default METRIC default IF default

ADD 10.7.0.0 MASK 255.255.240.0 default METRIC default IF default

ADD 10.8.0.0 MASK 255.255.240.0 default METRIC default IF default

clip_image012

Save the file, and connect again. You should now be able to RDP to all other VMs in the spoke VNets.

Hope this helps and for any questions feel free to contact me through my Twitter handle.

Wim Matthyssen (@wmathyssen)