https://docs.microsoft.com/archive/blogs/azurefoundation/feed.xml Business Performance Excellence Wed, 17 Apr 2019 03:19:08 GMT en-US hourly 1 https://docs.microsoft.com/archive/blogs/azurefoundation/credssp-prevents-remote-desktop-connection Thu, 10 May 2018 17:02:04 GMT https://blogs.msdn.microsoft.com/azurefoundation/?p=195 https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018 This is where I find out that my VMs are not auto updating.  I know, this isn't the best way to build VMs that don't automatically update, but I was in a hurry when I deployed the lab. The issue:  If I can't RDP to the server how can I run System Update? The solution: From a patched RDP server with network connectivity to your Azure server's that need to get this patch applied,

1. Get PSEXEC.exe
2. Get the PowerShell Script, PS_WinUpdate to update the VM.
3. Open a CMD prompt in Admin Mode
4. Run the following command:  psexec.exe -s \\w1padds1a cmd (this will open a remote command prompt on the RDS session)
5. Now that you have a remote session, run the powershell script:  powershell.exe c:\users\willstgov\documents\ps_winupdate.ps1 (I was able to get a mapped drive to the server and copy the script to the remote computer)

  This poor server needed to update a lot of things so it is still running :) Next steps will be to have an automation account running that updates the VMs the way they should be.   Will.        ]]> https://docs.microsoft.com/archive/blogs/azurefoundation/move-a-vms-primary-nic-from-one-vnet-to-another Thu, 18 Jan 2018 16:13:57 GMT https://blogs.msdn.microsoft.com/azurefoundation/?p=105 https://aka.ms/azure/foundation, is my repository, and you will find in the ARM directory structure there are specific patterns that will deploy an enterprise pattern.  Often things get deployed that don't follow the enterprise pattern and have to be moved into it. In this example, the powershell is hosted in the ARM/Compute/Utilities folder, with the name ModifyMVVNET.ps1. My approach was to apply the VNET migration to an entire subscription, where you can go through all the VMs and individually assign the VM a new network.  This was a horrible way to test my script, basically had to manually fix all the VMs manually.  After testing this out, I can see how you may prefer to apply the utility VM by VM, to compromise, I limited the scope to a ResourceGroup. Details for the PowerShell.

1. Login.  Note the $Environment variable, as my customers often are using the Government CloudLogin-AzureRmAccount -Environment $Environment
2. Focus on a Subscription.  One of my friends told me about the Out-GridView option!$subscription = Get-AzureRmSubscription | Out-GridView -PassThru
3. Focus on a ResourceGroup.$ResouceGroup = Get-AzureRMResourceGroup | Out-GridView -PassThru
4. Get the VMs in the ResourceGroup$VMs= Get-AzureRMVM -ResourceGroupName $ResouceGroup.ResourceGroupName
5. Cycle through the VM and help the user select the To-Be VNET and Subnet, as well as the Static IP address.
   • Select the new Network, hopefully knowing the current network information will help guide what network to choose. $NewNetwork = Get-AzureRmVirtualNetwork |Select-Object -property Name,Location,ResourceGroupName,AddressSpacetext | Out-GridView -passthru $NewNetwork = Get-AzureRmVirtualNetwork -Name $NewNetwork.Name -ResourceGroupName $NewNetwork.ResourceGroupName
   • Select the new Subnet $NewSubnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $NewNetwork | Select-Object -Property Name,AddressPrefix |Out-GridView -PassThru -Title $Title $NewSubnet = Get-AzureRmVirtualNetworkSubnetConfig -VirtualNetwork $NewNetwork -Name $NewSubnet.Name
   • Set the Private IP address variable $message = "current name: " + $vm.name + ", Current IP: " +$NIC[0].IpConfigurations.privateIPAddress+ ", New IP must be in this prefex: " + $NewSubnet.AddressPrefix $NewPrivateIP = Read-Host $message
   • Start a new IPConfiguration object $NewIPConfig = New-AzureRmNetworkInterfaceIpConfig -Subnet $NewSubnet -Name 'config1' -Primary -PrivateIpAddress $NewPrivateIP
   • Start a new NIC object $NewNic = New-AzureRmNetworkInterface -Name "$($NicName)1a" -ResourceGroupName $Nic.ResourceGroupName -Location $Nic.Location -IpConfiguration $NewIPConfig -Force
   • Since we are changing the Primary NIC, we need to remove the current NIC from the $VM. $VM = Remove-AzureRmVMNetworkInterface -VM $VM -NetworkInterfaceIDs $Nic.Id
   • Now the $VM doesn't have a NIC, so we can add the one in the new Subnet $vm = Add-AzureRmVMNetworkInterface -VM $VM -NetworkInterface $NewNic
   • OK, have your change tickets ready!  We will stop the current VM and we'll have to remove it since that is the only way to get our NIC associated to the VM. Stop-AzureRmVM -Name $VM.Name -ResourceGroupName $Vm.ResourceGroupName -Force Remove-AzureRmVM -Name $VM.Name -ResourceGroupName $Vm.ResourceGroupName -Force
   • Next we create the new VM, using the $VM we have in memory, with the only change to the definition of the $VM being the network interface.  This step has turned out to be challenging.  Some VMs have Data Disks, some don't.  Some VM's may be Linux, some Windows.   The best way to illustrate the work done is to look at the PowerShell. $NewVM = $newVMConfig | New-AzureRmVM -ResourceGroupName $vm.ResourceGroupName -Location $vm.Location

Some concepts to add:

• Add Extensions, in other words if the VM has extensions, make sure they get added back. $vm.extensions
• Clean up the old NICs by removing them

]]>