hyper-v – Page 2 – A Geeks World

List all VM’s with a Dynamic MAC Address

Short, simple script to list all VM’s which has NIC’s with a Dynamic MAC Address set.

# Get all VM's from Localhost (change to SCVMM Server if running remote) 
$AllVMS = Get-SCVirtualMachine -VMMServer localhost
$DynamicVMs = @()

# For each VM, check Virtual Network Adapters if Mac = Dynamic. 
foreach ($vm in $AllVMS ) {
   $vmnics = $vm | Get-SCVirtualNetworkAdapter
     if ($vmnics.MACAddressType -eq "Dynamic") {     
     $DynamicVMs += $vm.Name
     }
   }

# List all VM's with a Dynamic Mac address. 
$DynamicVMs | Sort-Object
Write-Output "--------"
$DynamicVMs.Count

# Get all VM's from Localhost (change to SCVMM Server if running remote)

$AllVMS = Get-SCVirtualMachine -VMMServer localhost

$DynamicVMs = @()

# For each VM, check Virtual Network Adapters if Mac = Dynamic.

foreach ($vm in $AllVMS ) {

$vmnics = $vm | Get-SCVirtualNetworkAdapter

if ($vmnics.MACAddressType -eq "Dynamic") {

$DynamicVMs += $vm.Name

}

# List all VM's with a Dynamic Mac address.

$DynamicVMs | Sort-Object

Write-Output "--------"

$DynamicVMs.Count

It will give a list of all VM’s and the number of VM’s in that list.
Small, simple and efficient.

Script for importing existing VMs into Azure Pack

As you start working with Azure Pack, you probably realize that you have a lot of existing VM’s that you would like to import into Azure Pack, and by that be able to use them just as you can handle all new ones?

All that’s needed for that, is to set the correct AzurePack user as the owner and SelfServicUuser on that Virtual Machine. And of course, have the machine in the correct “Cloud”.

Here is a small script which will help you out by;

Asking in a Grid View, which Cloud you would like to import a machine in.
Ask which user that should be the new owner of this VM.
Let you pick, which VM from the Cloud you would like to import.

As we have multiple clouds, and users can have multiple subscriptions, I chose to make the script use GridView, to minimize the risk for human errors (typos).

# You have to set your SCVMM server and use -ForOnBehalfOf to make use of SPF. 
$SCVMMSERVER = Get-SCVMMServer -ComputerName YOUR.SCVVM.SERVER.FQDN -ForOnBehalfOf 

$SCCloud = Get-SCCloud -Name (Get-SCCloud | select Name | Out-GridView -Title "Select Cloud" -PassThru).Name
$SCUser = (Get-SCUserRole | Where-Object Cloud -Match $SCCloud).Name -Replace "_.+","" | Out-GridView -PassThru -Title "Select User" 
$vmselfserviceuserrole = Get-SCUserRole | Where-Object Cloud -Match $SCCloud | Where-Object Name -Like $SCUser* 
$SCVM = (get-scvirtualmachine ($SCCloud | Get-SCVirtualMachine | select Name | Out-GridView -Title "Select VM" -PassThru).Name)

Set-SCVirtualMachine -VM $SCVM –UserRole $vmselfserviceuserrole –Owner $SCUser

# You have to set your SCVMM server and use -ForOnBehalfOf to make use of SPF.

$SCVMMSERVER = Get-SCVMMServer -ComputerName YOUR.SCVVM.SERVER.FQDN -ForOnBehalfOf

$SCCloud = Get-SCCloud -Name (Get-SCCloud | select Name | Out-GridView -Title "Select Cloud" -PassThru).Name

$SCUser = (Get-SCUserRole | Where-Object Cloud -Match $SCCloud).Name -Replace "_.+","" | Out-GridView -PassThru -Title "Select User"

$vmselfserviceuserrole = Get-SCUserRole | Where-Object Cloud -Match $SCCloud | Where-Object Name -Like $SCUser*

$SCVM = (get-scvirtualmachine ($SCCloud | Get-SCVirtualMachine | select Name | Out-GridView -Title "Select VM" -PassThru).Name)

Set-SCVirtualMachine -VM $SCVM –UserRole $vmselfserviceuserrole –Owner $SCUser

Computer account issues with vm snapshots

If you are often jumping back and forth between snapshots in your virtualized environment, you have probably had problems with computers that are unable to establish a secure connection with the domain. Basically, you have to rejoin the computer to the domain or reset password for the computer account, after restoring a snapshot. And you may question yourself, why this happens sometimes but not always?

You may see this in the eventlog

The session setup from the computer DomainMember failed to authenticate.
 The name of the account referenced in the security database is DomainMember$. 
 The following error occurred: Access is denied.

The session setup from the computer DomainMember failed to authenticate.

The name of the account referenced in the security database is DomainMember$.

The following error occurred: Access is denied.

The short explanation is, the password for the computers domain account does not match the one in AD, and have to be reset by either resetting the password or rejoining the domain.

The solution is to either create a script that resets the computer account, OR which is nicer but not always applicable in all environments, is to make sure the passwords always match!

There is a Local Security setting, which you can set on those computers that you need to restore (it’s a per computer setting so you don’t have to apply it to all of your computers). I usually do this in my Lab and Demo environments, so I can restore individual snapshots without worrying about this.

Just “Enable” the policy:

Domain member: Disable machine account password changes

Determines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.

Default: Disabled.

Domain member: Disable machine account password changes

Determines whether a domain member periodically changes its computer account password. If this setting is enabled, the domain member does not attempt to change its computer account password. If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.

Default: Disabled.

That will prevent those computers from changing their password in AD, so it will always match no matter which snapshot you jump back and forth to.
Though, the password changes for the computer account is a security precaution, disabling them could make it possible for a malicious user to get hold of the computer password and use it to Authenticate to the domain to read information.

The long(er) explanation:
A computer account is like a User Account, except for a few things. Like that a computer account password never expires, So even if you define that your users have to set a new password every 30 days, your computer accounts could use the same password for ever.

A Windows computer (client or server) will do a client side initiated password change according to the policy.

Domain member: Maximum machine account password age 
This security setting determines how often a domain member will attempt to change its computer account password. 
Default: 30 days.

Domain member: Maximum machine account password age

This security setting determines how often a domain member will attempt to change its computer account password.

Default: 30 days.

This means, that the client will by default initiate a password change every 30 day, when it has contact with the Domain. If the password change is successful, it will store the previous password as “OldVal” (Old Value) and the new Password as “CurrVal” (Current Value) in the registry at HKLM\SECURITY\Policy\Secrets\$machine.ACC.
If the client does not have contact with the Domain but the password is older than 30 days, it’s going to check (by default) every 15 minute if there is a Secure Channel to a DC and if it can initiate a password change.

When a client is booting, it will try to logon to the domain with the current password, if that fails, it will try with the previous password as a fail safe, in case the new password has not replicated to the other DC’s yet.

The reason a computer can join a domain with a pre-staged account where you as a user does not have the “Domain Join” permissions, is that the computer will simply logon with username: computername and password: computername$ (small letters with a $ at the end), and when the client has joined the domain, it will initiate a password reset and set a secure password.

And as stated above, the cool thing is that these policy settings are per computer. So you can use the 30 days default for all of your domain, except for a few computers that’s being used in testing or for application packaging where you regularly restore your snapshots.

The 30 day password change, is also the reason it’s so common to search the AD for inactive computer accounts by looking at the last password change. If the client has not changed password in the last ~90 days, it’s probably not in use anymore and the computer account can be deleted or inactivated.

There is a great article on this subject “Machine Account Password Process” written by the Microsoft “Directory Services Team” if you want even more in-depth information on Computer Account Passwords.

Can’t access a computer remotely without password?

I got a question the other day, “how can i access a computer remotely without a password?”

The reason that it’s by default is not possible to access a computer remotely with an account that does not have a password is because there is a new security policy/feature which states:

Accounts: Limit local account use of blank passwords to console logon only

This security setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. If enabled, local accounts that are not password protected will only be able to log on at the computer's keyboard.

Default: Enabled.

Accounts: Limit local account use of blank passwords to console logon only

This security setting determines whether local accounts that are not password protected can be used to log on from locations other than the physical computer console. If enabled, local accounts that are not password protected will only be able to log on at the computer's keyboard.

Default: Enabled.

You can change that behavior by modifying the “Local Security Policy” here:

Just a thought. One could argue that it’s actually safer to have no password on the Local Admin account and leave this policy Enabled. Than have a weak password on the Admin account.

Because if there is no password, no malicious person or software could ever remotely access the computer as a local admin. While if you have a weak password, it would be possible for someone to brute force (try all possible combinations until you get in) the password.