A frequently asked question about rolling out Azure VNet with different subnets in a infrastructure as code environment is where and how to define the subnets in your Azure ARM template. In the most examples online the number of subnets is configured in the template and the name and addressPrefix is configured in the parameter file. The big disadvantage with this scenario is that when you deploy a VNet with for example two subnets and later you decide to add more subnets you have two choices both of which are uncomfortable for an Infrastructure as code release pipeline. Continue reading Infrastructure as Code – Deploy Azure VNet with dynamic subnets
At the moment of writing this blog it’s unfortunately not possible to move an Azure VM with Managed disk to another Resource Group or to another Description. However, Microsoft says on the Azure Portal that this will be possible in the near feature. For the time being, I have chosen to write a small PowerShell script that will do the move fully automated for you. At the moment the only way to move an Azure VM with Managed Disk to another resource group is redeploying the VM. To achieve this you need to perform the following steps (some from the portal and some from PowerShell) manually:
- Shutdown VM
- Collect the required information like Networking, VM size, Storage etc.
- Create a Snapshot
- Create or use an existing Azure Storage Account to copy the Snapshot to
- Remove the VM
- Create a new Azure VM in the new Resource Group with the collected information and Snapshot disk from the Azure Blob
- The Azure VM will start automatically, check if the VM functions as it should and remove the Snapshot and Azure Storage Account.
As you can see there are about 7 steps needed to move an Azure VM with a Managed Disk. The script that I have written will do all the steps automatically with only 3 variables that you need to define while running the script. Continue reading Move Azure VM with Managed Disk to another Resource Group
Currently when you try to install the KMS Host License Pack for Office 2010 on a Windows Server 2016 or Windows 10 you receive the following error message:
The cause of this problem relies in the VBS script that is being triggered at the end of the installation. In order to install the KMS Pack on newer operating systems than Windows server 2008R2 you need to perform the following steps:
- Run KeyManagementServiceHost_en-us.exe until the error message appears. Don’t click OK.
- Go to the folder “C:\Program Files (x86)\MSECache\OfficeKMS” and copy the folder to somewhere like (C:\Temp\OfficeKMS)
- Click OK on the error message and press ENTER to close the program.
- Open the folder with the copy (C:\Temp\OfficeKMS) and edit the file kms_host.vbs:
- Search for the line
If (Ver(0) = "6" And Ver(1) >= "2") Or (Ver(0) >= "7") Then
- And replace it with the line below, this line just says that Windows Server 2016 and Windows 10 (both having version number 10) are also supported:
If (Ver(0) = "6" And Ver(1) >= "2") Or (Ver(0) >= "7") Or (Ver(0) = "10") Then
- Start Command prompt with administrative permissions, run the command below and follow the wizard.
cd C:\Temp\OfficeKMS cscript.exe kms_host.vbs
- Search for the line
Disable Office 2016 – First things first Prompt
When you first launch Office Click to Run or Office 2016, you will get a First things first dialog box come up like below. Users will always click accept, what other choice do they have?
You can disable this by configuring the below Registry key:
Disable Office 2016 Default File Types Dialog
Another thing I disable on my desktop builds is the Office 2016 Default File Types prompt as shown below. Normal users will not understand what it means. All they will do is ask questions.
Use the registry key below to stop it appearing :
When you are performing a PXE boot, most of the time you need to press F12 to trigger the PXE boot action. Then after connection is initiated with the PXE server, the boot rom image asks for the F12 key to be pressed again. If the key is not pressed, the machine will continue to boot normally into the installed OS (if available). This can be confusing for some Admins because they except the client to boot through to the Boot image, or maybe they want to create a fully automated OSD Deployment. Continue reading Disable F12 confirmation at PXE boot into WinPE