Windows Server 2019: The component store has been corrupted. Error 0x80073712
Hi all, I'm trying to install the Server Backup feature on our 2019 Server, but it results in this error: Any ideas on what may have caused this, and how to solve it? The server was installed about 5 months ago, and the installation is basically stock, not much changes made. Thanks in advance.Login to Windows virtual machine in Azure using Azure AD authentication (and the pitfalls)!
Dear Microsoft Azure Friends, This article is about the login to Windows virtual machine in Azure using Azure Active Directory authentication and what needs to be considered in the process. This article describes the procedure. So far, everything is actually in perfect order. https://docs.microsoft.com/en-us/azure/active-directory/devices/howto-vm-sign-in-azure-ad-windows So I have worked through the steps and now I want to log on to the virtual machine with an Azure Active Directory account. Why does this error message appear now? Have I done something wrong? I am going through all the steps again. No fits. So I take another close look at the article and discover the following: But that's exactly not the case with me. I want to connect from my local system which is not registered or joined in Azure. Let's take it one step at a time. First of all, I create a group in Azure Active Directory. This will contain the account I will use later for the login. ATTENTION: Use the appropriate Windows OS => Windows Server 2019 Datacenter edition and later or Windows 10 1809 and later Next I create a new virtual machine with the default settings (including a public IP address and yes this is not good, but this demo absolutely OK). Except for Management I set the following settings. If you want to work with an existing virtual machine you need to install the extension. You can do this with the Azure Cloud Shell, in a Bash terminal. az vm extension set \ --publisher Microsoft.Azure.ActiveDirectory \ --name AADLoginForWindows \ --resource-group YourResourceGroup \ --vm-name YourVM After the virtual machine is created we need to work with Role based Access Control RBAC. There are two roles that can be used. Virtual Machine Administrator Login or Virtual Machine User Login If you need local admin rights you need the first role. If you want to log in as a standard user, you can work with the second role. Now we connect to the virtual machine using RDP, but ATTENTION, I use the account I created when I created the virtual machine (not an Azure AD account). In the virtual machine I start the command prompt and use dsregcmd /status. The machine is Azure AD Joined. In the virtual machine, navigate to Start and invoke "run". Type sysdm.cpl and navigate to the Remote tab. Remove the "Allow connections..." option and click "Select Users". When you click on "Locations" you will immediately see that you cannot select an account from Azure AD. We need the command prompt for this. Start the command prompt with elevated privileges and enter the following (customized with your information, of course). net localgroup "remote desktop users" /add "AzureAD\Email address removed" Go back to the Azure Portal to your virtual machine. Download the RDP connection file. Open this RDP file with an editor and add the following lines. enablecredsspsupport:i:0 authentication level:i:2 Now double click on the RDP connection file and now use the Azure account for login. AND BINGO, we can now log in to our virtual machine using the Azure Active Directory account! Cool! I hope this article was useful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
How to get the Windows Server 2016 licence key on an installed system?
Hi there! How to get the Windows Server 2016 licence key on an installed system? Many tools don't support Windows Server 2016 officially, and, so it seems, every tool prints out another key on that System: - https://gallery.technet.microsoft.com/scriptcenter/Get-Windows-Product-6b5e6f6e - http://www.nirsoft.net/utils/product_cd_key_viewer.html - https://neosmart.net/OemKey/ Does somebody know it works with Windows Server 2016? -> https://www.magicaljellybean.com/keyfinder/ Thank you for your feedbacks! :-) With best regards, JanAdd drivers to the Windows Server 2019 ISO Image
In this blog article, I am going to show you how you can add drivers to a Windows Server 2019 ISO Image or WIM file using PowerShell and the DISM module. This will allow you to already have the latest drivers within the Windows Server installation image when you install Windows Server 2019. Find more here: https://www.thomasmaurer.ch/2019/07/add-drivers-to-a-windows-server-2019-iso-image/Create a snapshot of a VM with PowerShell in Azure
Hi Azure friends, I used the PowerShell ISE for this configuration. But you are also very welcome to use Visual Studio Code, just as you wish. Please start with the following steps to begin the deployment (the Hashtags are comments): #The first two lines have nothing to do with the configuration, but make some space below in the blue part of the ISE Set-Location C:\Temp Clear-Host #So that you can carry out the configuration, you need the necessary cmdlets, these are contained in the module Az (is the higher-level module from a number of submodules) Install-Module -Name Az -Force -AllowClobber -Verbose #Log into Azure Connect-AzAccount #Select the correct subscription Get-AzContext Get-AzSubscription Get-AzSubscription -SubscriptionName "your subscription name" | Select-AzSubscription #Set some parameters $resourceGroupName = 'tw-rg01' $location = 'westeurope' $vmName = 'tw-winsrv' $snapshotName = 'mySnapshot' #Get the VM $vm = Get-AzVM -ResourceGroupName $resourceGroupName -Name $vmName #Create the snapshot configuration $snapshot = New-AzSnapshotConfig -SourceUri $vm.StorageProfile.OsDisk.ManagedDisk.Id -Location $location -CreateOption copy #Take the snapshot New-AzSnapshot -Snapshot $snapshot -SnapshotName $snapshotName -ResourceGroupName $resourceGroupName #Next steps in the Azure Portal #Create a virtual machine from a snapshot by creating a managed disk #from a snapshot and then attaching the new managed disk as the OS disk Now you have used the PowerShell to create a snapshot of virtual machine! Congratulations! I hope this article was useful. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerUse PowerShell to search for accounts in Active Directory that have gone stale!
Dear Microsoft and Active Directory Friends, In a company/organization, employees come and go. This is completely normal and nothing out of the ordinary. But often, from a technical point of view, the Active Directory is somewhat forgotten and account cleanup is rarely or never done. This means there are outdated or no longer current accounts (ghost accounts). This is not a great situation from either a security or administrative perspective. In this article I would like to show you a possible way. But what exactly does "stale" accounts mean? Let me explain my definition to you: 1. Haven't logged in for X days 2. Hasn't logged in 3. Created at least X days ago We can start first with the CMDLET "Search-ADAccount". This gives once a first result. The #tags are comments. #Using Search-ADAccount Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly How many accounts would there be? (Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly).count But there are a lot of them. Now let's work with filters. We explicitly examine the "LastLogonTimeStamp" property. For an account that has never been logged in, no value is displayed. #Using a filter Get-ADUser "Freida Lazarus" -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp An account that has been used for a login will show a value. This number represents a date, this is in FileTime format. We can generate such value. For example, one hour in the past. $LogonDate = (Get-Date).AddHours(-1).ToFileTime() $LogonDate So, for example, we can check who has not logged in during the last hour. Of course we would not work with only one hour. But I'm going to keep working with this one hour so I can illustrate it to you better. #If it is older than $LogonDate $LogonDate = (Get-Date).AddHours(-1).ToFileTime() Get-ADUser -Filter {LastLogonTimeStamp -lt $LogonDate} Or in numbers it would be so many accounts. Now we search for all accounts that do not have this value. #If it doesn't have value Get-ADUser -Filter {LastLogonTimeStamp -notlike "*"} -Properties LastLogonTimeStamp | Select-Object Name,LastLogonTimeStamp But what if the user has not yet logged in because the account has just been created? Let's take a closer look at this as well. #And if the account was created before $createdDate $createdDate = (Get-Date).AddDays(-14) Get-ADUser -Filter {Created -lt $createdDate} -Properties Created | Select-Object Name,Created Bringing all this together, we can determine what exactly "stale" means to us. #Add them all together: $filter = { ((LastLogonTimeStamp -lt $logonDate) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdDate) } Get-ADuser -Filter $filter | Select-Object SamAccountName We can create a function from it. Function Get-ADStaleUsers { [cmdletbinding()] Param ( [datetime]$NoLogonSince = (Get-Date).AddDays(-90), [datetime]$CreatedBefore = (Get-Date).AddDays(-14) ) $NoLogonString = $NoLogonSince.ToFileTime() $filter = { ((LastLogonTimeStamp -lt $NoLogonString) -or (LastLogonTimeStamp -notlike "*")) -and (Created -lt $createdBefore) } Write-Host $filter Get-ADuser -Filter $filter } # Usage Get-ADStaleUsers This way we can work with our own values. Moreover, we can delete the accounts directly afterwards or at least check with -WhatIf what exactly would be done! Get-ADStaleUsers -NoLogonSince (Get-Date).AddDays(-30) -CreatedBefore (Get-Date).AddDays(-7) | Remove-ADUser -WhatIf Annotation: In the search result from above two Built-In accounts (e.g.: krbtgt) are displayed among others (this is how it turned out in the search). Such Built-In accounts should never be deactivated or even worse deleted, this has very negative effects on the function of the Active Directory. You should never delete user accounts directly. Instead, the accounts should be disabled for some time first. If the accounts were used for other purposes (unknown to you). You should also avoid setting user accounts as service accounts. This is not according to Microsoft "Best Practice". For service accounts, use the so-called group managed service accounts. I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechslerPersistent Virtual Machines provisioningState "Updating"
Hi, I'm trying to use Ansible to manage my Virtual Machine state via Ansible and some unexpected behaviour popped up. The Azure VM provisioningState never changed from "Updating" to "Succeeded" while the VM is running and available. I've validated this by querying the API using the Azure-CLI tool and checking : > az vm show -g cloudVMrg -n cloudVM |jq '.provisioningState' "Updating" After some searching it seems that this state is represented as is registered in Azure for the Virtual Machine. The state value "Updating" seems to me as an intermediate state whereafter Completed should be set. It seems that this doesn't or didn't happen in my case. The VM is started and available (I can SSH on to the machine) but its provisioningState is still "Updating". On Azure (see attached images) the changes logged on the VM confirm that the value was changed from "Succeeded" to "Updating" when the VM was changed from deallocated powerState. Is this a bug? What is a valid less intrusive and sustainable (automatable) workflow to resolve this issue? What is an effective (stateless) way to monitor this? I've followed this instruction however it doesn't exactly match my case, but it fixed the provisioningState; command ran like 10 minutes. Resolution - https://docs.microsoft.com/en-us/troubleshoot/azure/virtual-machines/vm-stuck-in-failed-state?tabs=cliSet up and configure Microsoft Local Administrator Password Solution (LAPS)!
Dear Microsoft and Active Directory Friends, Imagine the following scenario. All your systems (Windows clients) have been set up on the basis of a so-called "golden image". "Golden image" means that you have set up a reference system, made all settings, installed apps, etc. Then shutdown the system with Sysprep (generalized). Then set up all other clients with this image. This is all great, but by setting up the Windows client with the "Golden Image", the same password is now available for the local administrator account on every system. Oops! But why should that be a problem? Here is my personal top 3 why this is a bad idea: 1. Employees leave the company knowing these passwords. 2. If all passwords are the same, a lateral pass-to-hash attack is simplified in the event of an infection or attack. 3. If you ever have to give a password to the user (yes, shouldn't happen, but can), then they know the password for all systems. This is where Microsoft Local Administrator Password Solution (LAPS) comes in. Now let's start setting up Microsoft LAPS together. First of all, we need the necessary software. You can download everything you need here: https://www.microsoft.com/en-us/download/details.aspx?id=46899 There are two components in the .msi file I selected. First, the client-side extension (a kind of agent) and the administration components (a small GUI). But we'll look at that a little later. Now that we have downloaded the "tool". We continue in the Active Directory. First we need to check where the client systems are (in which organizational unit) so that we can later configure them with PowerShell. Now we know where the client systems are. Now let's start with the installation of the management tools. In my test environment I use the DC01 system (this is a domain controller) because I have no other system available. You can also use another server for this. As you can see there are several components which can be installed. The default is to install the CSE only. I have customized this selection because I want to install the management tools on this system. File Reference: The installation for the Fat client UI is done to folder: %ProgramFiles%\LAPS AdmPwd.UI.exe AdmPwd.Utils.config AdmPwd.Utils.dll The installation for the PowerShell modules is done to folder: %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS AdmPwd.PS.dll AdmPwd.PS.format.ps1xml AdmPwd.PS.psd1 AdmPwd.Utils.config AdmPwd.Utils.dll %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS\en-us AdmPwd.PS.dll-Help.xml The installation for the Group Policy files is done to folders: %WINDIR%\PolicyDefinitions AdmPwd.admx %WINDIR%\PolicyDefinitions\en-US AdmPwd.adml Next, we will customize the schema right away on this system using PowerShell. For this I use the PowerShell ISE with elevated privileges. Of course you can use the editor you feel comfortable with. (# are Comments) #Extend the AD Schema Import-module AdmPwd.PS Update-AdmPwdADSchema Now we need to adjust the permissions of the computer objects. This is required so the machine can update the password and expiration timestamp of its own managed local Administrator password. #Change Computer object permissions Set-AdmPwdComputerSelfPermission -OrgUnit "Clients" Add the permission (extended right) on the computer accounts to group(s) or user(s) that will be allowed to read (and also the write permissions if you wish) the stored password of the managed local Administrator account on managed computers. #Assign permissions to the group for password access #The extended permissions are only applied to the Domain Admins group Find-AdmPwdExtendedRights -Identity "Clients" #We need to grant the read permissions to "ITAdmins" Security group Set-AdmPwdReadPasswordPermission -Identity "Clients" -AllowedPrincipals prime\ITAdmins #We need to grant the write permissions to "ITAdmins" Security group Set-AdmPwdResetPasswordPermission -OrgUnit "Clients" -AllowedPrincipals prime\ITAdmins #Let's check Find-AdmPwdExtendedRights -Identity "Clients" Now we move on to the group policies. In my test environment there is a so-called central policy store. Depending on how your environment is set up, you need to make sure that the following files are also available at your end. If you are using a central policy store, copy the following two files to the central policy store. The two files can be found in the following path: %WINDIR%\PolicyDefinitions AdmPwd.admx %WINDIR%\PolicyDefinitions\en-US AdmPwd.adml It continues with the creation of a new group policy. Open Group Policy Management and create a new Group Policy object. The settings are located under Computer Configuration\Administrative Templates\LAPS Management of password of local administrator account must be enabled so as the CSE can start managing it. By default this solution uses a password with maximum password complexity, 14 characters and changes the password every 30 days. You can change the values to suit your needs by editing a Group Policy. If you have decided to manage custom local Administrator account, you must specify its name in Group Policy (In my example it is admin). If you do not want to allow setting planning password expiration of admin account for longer time than maximum password age, you can do it in GPO. Now we need to link our new group policy object to the correct "location". Now, before we update the group policies on the client systems, we install the AdmPwd GPO extension on the clients. These can be installed/updated/uninstalled on clients using a variety of methods including the Software Installation feature of Group Policy, SCCM, login script, manual install, etc. If you want to script this you can use this command line to do a silent install: msiexec /i <file location>\LAPS.x64.msi /quiet or Just change the <file location> to a local or network path. Example: msiexec /i \\server\share\LAPS.x64.msi /quiet Now update the group policies and restart the system out of habit. Now we check if everything works as prepared. In the Active Directory Users and Computer tool, make sure that you have selected the advanced features. Right click on the Computer object and switch to the Attribute Editor tab and lo and behold, the password is displayed here. Now let's look at the password in the LAPS graphical tool. Exactly the same password. Great! Works also with the PowerShell. To manually reset the password, just click the Set button in LAPS UI tool. When a Group Policy refresh runs, password will be reset. You can also plan password expiration for the future. To do so, enter desired expiration date/time into respective field. You can also reset the password using PowerShell. For Example: I realize that this was not necessarily spectacular. It was simply important for me to share my experience with you. Nevertheless, I hope that this article was helpful. Thank you for taking the time to read the article. Best regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
