MBAM Policy Error code: -2147217402 on Windows 10 1903

I was installing MBAM 2.5 SP1 client on Windows 10 1903 during SCCM task sequence. Once the device was built and the user tried to put in a pin and start the encryption it would fail.

The below error was showing in the MBAM event logs. fail1 We currently install MBAM successfully on Windows 1809 so it didn’t look like a MBAM server issue or connection issue. I checked and there was a newer servicing release from May 2019

https://support.microsoft.com/en-us/help/4505175/may-2019-servicing-release-for-microsoft-desktop-optimization-pack

This update adds support for Windows 10 1903. I applied this update and can now encrypt successfully.

AD RDS Profile Removal PowerShell

I was having a issue with slow logon times and temporary profile when users where logging on to an Windows RDS 2012 farm. I had a look at the issue and it was down to the RDS profile path in AD being set to use an old decommissioned server. RDS1

Once I found the issue, I need to figure out how many users where affected so the easiest way I could do this was to use PowerShell.

Below is the report script that I used. The distinguished name used in Get-ADUser -searchbase will need to be update and the export path. (Test before running any script and also check the quotes and doubles quotes when copying)

## Get list of Users
$RDUsers = Get-aduser -SearchBase “OU=TestUsers,OU=Users,DC=Domain,DC=Local” -Filter *

## Set Results Array
$Results = @()

foreach ($user in $RDUsers){
$RD = [ADSI]”LDAP://$($user.DistinguishedName)”
if ($RD.Properties.Contains(“userParameters”)){

$profilepath = $RD.psbase.Invokeget(“terminalservicesprofilepath”)
$profileHome = $RD.psbase.Invokeget(“terminalServicesHomeDirectory”)
$props = @{
UserName = $user.SamAccountName
RDSProfile = $profilepath
RDSHome = $profileHome
DistinguishedName = $user.DistinguishedName
}

$Results += New-Object psobject -Property $props
}

else {
Write-Host “No UserParameters set on” $user.SamAccountName -ForegroundColor Green
}
}
$Results | Export-Csv C:\Temp\Logs\RDSProfile.csv -NoTypeInformation

RDS2

Once the script has completed the results will be export to a CSV with all user and there profile paths RDS3 Once we have the list we can either remove manually or the better option use the CSV and remove the profiles using the invokeset method.

Below is the script I used. The script could be run against all AD users but I prefer to limit the amount of object I have to run against. (This will replace values on users so should be fully tested before apply to large amount of users.)

$RDProfile = Import-Csv -Path C:\Temp\Logs\RDSProfile.csv
foreach ($RDU in $RDProfile){
Write-Warning “Removing Profile from $($RDU.UserName)”
$RD = [ADSI]”LDAP://$($RDU.DistinguishedName)”
$RD.psbase.Invokeset(“terminalservicesprofilepath”,”$null”)
$RD.psbase.Invokeset(“TerminalServicesHomeDirectory”,”$null”)
$RD.setinfo()
}

RDS4

After the script has run the profiles should now be cleared. RDS5

Surface Pro 6 1TB Disk 0 not found SCCM OSD

We recently started to build the new surface pro 6 1TB using SCCM. When imaging the task sequence kept failing at the format and partitioning step. When I checked the SMSTS log I could see the below errors

Invalid disk number specified: 0

OSDDiskPart.exe failed: 0x80070490

error1

From the error the problem was that there was no disk 0 available, I usually only see this when there are driver issues with the storage controller.

To check and see what disk where available, we can open a command prompt in the task sequence (As long as it’s enabled on the boot image) with F8 and run diskpart, once diskpart has opened use the list disk command to view available disk.

On the surface pro there was no disk 0 or 1 but instead the 1TB disk shows as disk 2 which is the reason the format is failing as by default the disk that is to be formatted and partitioned is disk 0.

I had a look online and the reason seems to be that the 1TB disk in the Surface Pro 6 is actually 2 x 512GB disk mirrored using Storage Spaces technology. See support KB below.

https://support.microsoft.com/en-us/help/4046108/disk0-not-found-when-you-deploy-windows-on-surface

This is why the disk shows as 2 and the default disk number is set to 0.

error2

The support KB says to change the format task to use disk 2 but this would require a second task sequence which is not ideal as it means more management overhead.

To work around this I have created an additional format and partition step in my existing task sequence and use WMI query’s to apply the specific format step for the Surface Pro 6 1TB.

WMI query to exclude device with no disk 0

Disk index: SELECT * FROM Win32_DiskDrive WHERE Index = “0” error3

WMI query for surface pro 6 1TB

Disk index: SELECT * FROM Win32_DiskDrive WHERE Index = “2”

Select surface pro device: SELECT * from Win32_ComputerSystem WHERE Model LIKE “%Surface Pro 6%” error4

Once the query is set on the format and partition disk step in the task sequence, set the disk number to 2. error5 Now I can image the surface pro 6 1TB model successfully.

Create Windows 10 Answer file

In a previous post we went through creating and deploying language packs there was an additional step to create a Windows 10 answer file, I though it might be helpful to do a post on creating a basic answer file using Windows System Image Manager (SIM).

First step is to install Windows Assessment and deployment kit (ADK). To download the latest ADK use the below link:

https://go.microsoft.com/fwlink/?linkid=2086042

Select deployment tools. UA2 Once the install has finished, go to the start menu and down to Windows Kits and open Windows System Image Manager .

UA4

First step is to select a Windows image file, to get the image file just need to extra the required Windows ISO to a folder. UA5 Below is the extracted ISO. UA12 Go to Sources > install.wim. UA6 Select the version. UA7 Next create a new answer file. UA8 Go to Windows Image

UA13

Select Components, on the components below is the different type and examples

amd_64 =64bit components, only used on x64 installs

wow_64 = 32bit components or support components for 32bit installed on x64, only used on x64 installs

x86 = 32bit components installed on x86, only used on x86 installs

I used “amd64_Microsoft-Windows-Shell-Setup_10.0.17763.1_neutral” > “OOBE” and click Add settings to Pass 7 oobeSystem.

Edit “amd64_Microsoft-Windows-Shell-Setup__neutral” to add in Register Owner and any other details as required. UA11 Next edit the required OOBE settings. UA10 Once all the settings have been added save the answer file. UA14 Last step is to create a package for the answer file and apply the answer file in the SCCM task sequence. UA15

Below is the content of the XML file.

<?xml version=”1.0″ encoding=”utf-8″?>
<unattend xmlns=”urn:schemas-microsoft-com:unattend”>
<settings pass=”oobeSystem”>
<component name=”Microsoft-Windows-Shell-Setup” processorArchitecture=”amd64″ publicKeyToken=”31bf3856ad364e35″ language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”>
<OOBE>
<HideEULAPage>true</HideEULAPage>
<HideLocalAccountScreen>true</HideLocalAccountScreen>
<HideOEMRegistrationScreen>true</HideOEMRegistrationScreen>
<HideOnlineAccountScreens>true</HideOnlineAccountScreens>
<HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE>
<ProtectYourPC>3</ProtectYourPC>
<SkipMachineOOBE>true</SkipMachineOOBE>
<SkipUserOOBE>true</SkipUserOOBE>
</OOBE>
<RegisteredOwner>TheSleepyAdmin</RegisteredOwner>
</component>
</settings>
<cpi:offlineImage cpi:source=”” xmlns:cpi=”urn:schemas-microsoft-com:cpi” />
</unattend>

Deploying Microsoft LAPS Part 3

In the last post we went through deploying the LAPS agent using a script, GPO or SCCM. The next step is to configure the GPO settings to apply LAPS management policy’s

First, we create a new GPO to apply the LAPS management policy’s, the LAPS policy’s are under Computer Configuration > Polices > Administrative Templates > LAPS (If this doesn’t show the ADMX template is probable missing and will need to be installed. This can be done using the LAPS installer) LAPSGP1 Password settings policy used to set the password complexity, length and age LAPSGP2 Specify the account that the password policy will apply to if this is the default administrator account this should be left at default LAPSGP3 LAPSGP4 Enabled management of local admin account LAPSGP5 Once the policy is configured apply the policy against the required OU LAPSPass1 To confirm that all settings are working, run a gpupdate on a test device. Once applied we can check the password in a few different ways

First way is to run PowerShell command: LAPSPass

Second way is to use the LAPS UI , this can be either used from the management server or installed on local computer using the LAPS installer and selecting the LAPS management tools

LAPSPass2 LAPSPass3

The third method is to check the AD computer attribute ms-Mcs-AdmPwd: LAPSPass4

Last step is to set delegated access to a security group or set of users to view and reset the local administrator password. Use the below command to verify the current rights

Find-AdmPwdExtendedRights -identity:OU distinguishedName

LAPSPass5 There are two command to set the rights, one for read and one for reset rights

Set-AdmPwdReadPasswordPermission -OrgUnit OU distinguishedName -AllowedPrincipals “HelpDesk_LAPS_Access”

Set-AdmPwdResetPasswordPermission -OrgUnit OU distinguishedName -AllowedPrincipals “HelpDesk_LAPS_Access”

LAPSPass6 Last step is to verify the permission have been applied LAPSPass7

LAPS is now deployed and ready to use.

Deploying Microsoft LAPS Part 2

In the last post we went through installing LAPS management tools, extending the AD schema and setting the delegation rights for computer OU to allow computer to write back to the LAPS password attribute.

The next step is to install the LAPS client this can be done either by using a script, group policy or SCCM.

I used the below the script to install remotely just need to create the complist with host name of devices and update the sharename and verions of LAPS that is required

$Computers = Get-Content “C:\Temp\complist.txt”
foreach ($Computer in $Computers){
Write-Warning “installing LAPS on $Computer”
$command = “msiexec /i C:\windows\temp\LAPS.x64.msi /quiet”
$Remotecmd = “CMD.EXE /c ” + $command
Copy-Item \\sharename\LAPS.x64.msi -Destination \\$Computer\c$\windows\temp\
Invoke-WmiMethod -class Win32_process -name Create -ArgumentList $Remotecmd -ComputerName $Computer | Out-Null
}

The second option is to deploy using GPO software install

Craete a new GPO > Policies > Software settings > software installtion > New package LAPS6 Add the installer LAPS7 LAPS8 LAPS9 Next apply the policy agaist the OU or use security filtering to apply to specific devices once the policy is applied logon to the device and run gpupdate /force to apply LAPS10

Third option is to use a tool like SCCM to package the application and deploy to devices. This would be my preferred way as its gives the best reporting.

We won’t go through the process but the command line install will msiexec /i C:\windows\temp\LAPS.x64.msi /quiet LASCCM LASCCM1

Deploying Microsoft LAPS Part 1

In this post we will be going through deploying and configuring Microsoft LAPS (Local Administration Password Solution). LAPS is a solution to automate the changing of a local administrator account on every computer in the domain.

To install LAPS will require a management server / workstation I will be installing on my domain controller.

Supported Operating System

Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Vista

Active Directory: (requires AD schema extension)
• Windows 2003 SP1 or later.
Managed machines:
• Windows Server 2003 SP2 or later, or Windows Server 2003 x64 Edition SP2 or later.
Note: Itanium-based machines are not supported.
Management tools:
• .NET Framework 4.0
• PowerShell 2.0 or later

First step is to download the install files for LAPS

https://www.microsoft.com/en-us/download/details.aspx?id=46899

Next install the full deployment of LAPS on the designated management server / workstation.

Run LAPS installer for operating system verison LAPS1 LAPS2 LAPS3

Install full management tools LAPS4 LAPS5

After the management tools have been installed the next step is to extend the AD schema

The LAPS PowerShell module is called AdmPws.PS LAPSAD1

To update the Schema first add the LAPS module and then run

Update-AdmPwdADSchema LAPSAD2

Last step is to delegate right to computer objects to allow them to write to the ms-MCS-AdmPwd and ms-Mcs-AdmPwdExpirationTime AD attributes.

Set-AdmPwdComputerSelfPermission -OrgUnit “OU=Computers,DC=Domain,DC=local” LAPSAD4

In the next post we will go through delegating access to specific users to allow them read the ms-MCS-AdmPwd attribute and to deploy the LAPS client through SCCM , script and GPO.

Configure Azure Site Recovery for VMware

Azure site recovery (ASR) is a DR / Migration tool from Microsoft and can be used to configure DR between data centers or Azure.

In this post we will be going through setting up ASR to replicate a VM from VMware to Azure.

There are some limitations for ASR these are listed the below link

https://docs.microsoft.com/en-us/azure/site-recovery/vmware-physical-azure-support-matrix

The main limits for VMware are guest disk need to be less than 4TB and vCenter needs to be at least 5.5.

I have a previous post on how to configured a recovery service vault so I wont be going over that again but if you need to configure here is the previous post.

https://thesleepyadmins.com/2018/11/23/azure-vm-backup-using-azure-recovery-service-vault/

Logon to Azure

Go to Recovery Services vaults

ASR1 Go to the already configure vault, select Site Recovery and click on prepare infrastructure ASR2 Once the wizard has started select the require goals ASR3 I am not running the planning tools as this is a test but it is recommended to run before starting a deployment to verify the required bandwidth. ASR4 Next we will download the OVA appliance that will be imported to VMware ASR5 Once the OVA has been downloaded and imported to VMware on boot up the server will require you to read / accept a licence agreement and provide an administrator password.

Give the server a name (this will show up in as the configuration server in Azure after the setup as been completed) ASR6 Next step is to sign in to Azure tenant that the server will connect to for replication ASR8 Next we will go through the configuration steps first step is to set the interface that will be used to connect to on-prem devices & connection back to Azure there can be two different NIC’s assigned if required. ASR9 Next is to configure the Recovery vault that will be used, select the subscription, the recovery vault RG and recovery service vault that has been configured. ASR10 Install the MySQL software ASR11 Next a validation test will run. (I am getting a warring for memory and CPU as I didn’t have enough memory / CPU and had to edit the VM to run on less resource but it will still complete) ASR12 Next is to connect to the vCenter server that is running the VM’s that are to be replicated to Azure. ASR13 Last step will configure the configuration server in Azure. ASR15 Once this has been completed we can go back to the Azure portal and we should now see the configuration server show under prepare infrastructure setup ASR16

Select the subscription and deployment model to be used for failover I am using Resource Manager ASR17 Next create a replication policy to apply to the ASR configuration server. ASR18 ASR19 Once the configuration is done we can now protect and replicate our on-prem VM’s , go back to site recovery and select step 1: Replicate Application ASR20 Select source, source location (Configuration server on-prem)Machine type (Physical / virtual), vCenter (If virtual) and the process server ASR21 Select the subscription, RG that the VM will replicate too and the deployment model ASR22 Next select the server that will be replicated the VM must be powered on and be running VMware tools be available for replication other wise they will be grey-out ASR23 Select the required disk type, storage account ASR24 last step is to assign the policy required (Multiple policy can be created base on the recovery time requirements and retention times) ASR25

Last step is to enabled replication

ASR26

Once enabled check the site recovery jobs to see the progress ASR27 Once replication has completed we can create a recovery plan, go to recovery Plans (Site Recovery and select Recovery plan ASR28 Give the plan a name, select source, target , deployment type and select the VM’s that will be added to the recovery. ASR29 ASR31

Azure Migrate Services Setup

With more companies looking to move workloads from on-prem to cloud providers, it can be difficult to work out the cost for current workloads.

In Azure we can utilize Azure Migrate Services.

At the time of this post VMware is only supported, this will be extended to Hyper-v in future releases. VMware VMs must be managed by vCenter Server version 5.5, 6.0, 6.5 or 6.7.

In this post we will be going through the process off assessing the on-prem VMware environment and view the assessment report.

The environment we will be assessing is VMware vCenter 6.7 and ESXi 6.7 and a VM running Windows Server 2016.

The architecture of the Azure Migrate Service is shown in the following diagram

AZMIG

Below is the process

Create a project: In Azure, create an Azure Migrate project
Discover the machines: Download collector VM as an OVA and import to vCenter
Collect the information: The collector collects VM metadata using VMware PowerCLI cmdlets. Discovery is agentless and doesn’t install anything on VMware hosts or VMs. The collected metadata includes VM information (cores, memory, disks, disk sizes, and network adapters). It also collects performance data for VMs
Assess the project: The metadata is pushed to the Azure Migrate project. You can view it in the Azure portal.

Logon to Azure

Go to All services search for migration project AZMIG_1

Select Create migration project

AZMIG_2

Give the project a Name, subscription, Resource group & Geography

AZMIG_3

Select Discover & Assess AZMIG_4

Select Discover and Assess. then Discover machines AZMIG_5 download OVA. The system requirement for the OVA are:

CPU: 8 vCPU’s; Memory: 16GB; HardDrive: 80GB AZMIG_6

Next step is to import the OVA to VMware

Go to vCenter

AZMIG_7

Browse to the OVA file location and select AZMIG_8 Select the Name and location of the OVA AZMIG_9 Select the destination cluster AZMIG_10 Click Next AZMIG_11 Select destination data store and specify either thick or thin provisioned disk AZMIG_12 Select the port group tha the VM will use AZMIG_13 Review and confirm settings AZMIG_14

Once the OVA is imported, power on the VM

Read and accept the license terms and give the collector an admin password.

Log into the VM and run the connector utility on the desktop.

AZMIG_15

Got through the prerequisites checks AZMIG_16

Next step is to connect to the vCenter. Put in the vCenter IP or hostname, Username / Password and once connect select the cluster or host that is currently running the VM’s that need to be assessed for migration.

AZMIG_17

Next step is to connect back to Azure using the migration project credentials that were generated when creating the project AZMIG_19 AZMIG_18

Click continue and the last screen will start the discovery this can take a while to complete (60 minutes or so) AZMIG_20

Once the discovery has completed, we then need to Create assessment AZMIG_21

Create a new group and select the VM that will be assessed AZMIG_22

Once this has completed go to Overview and click on the assessment AZMIG_23

Once in the assessment you can see the readiness of your VM and the Monthly estimated cost for running the workloads and AZMIG_24

Click on the VM to view specific details and performance stats AZMIG_25

We can now see what the cost will be for migrating workloads to Azure and this can be presented to give a better understanding of the cost savings that can be achieved with cloud migrations.

Configure Branch Cache SCCM 1810

We recently started to roll out Windows 10 and started to see spikes on our WAN links caused by the increased size of updates. We look at installing local DP on each site but this would add a lot of over head for managing these DP’s.

We then looked at using branch cache, I decided to do a post on enabling branch cache in SCCM.

First I need to check on clients if branch cache was enabled to do this run the below command.

netsh branchcache show status all

BC1

Once confirmed we need to enable branch cache in SCCM client settings this can be either enabled on an existing device policy or create a new policy I am going with a new policy.

Logon to SCCM Admin console > Administration > Client settings

Right click on client settings > Create Custom Client Device Settings BC2

Give the policy a Name and select Client Cache Settings BC6

set the below settings

Change Configure BranchCache to Yes
Change Enable BranchCache to Yes
Configure the cache size settings (default is 10%)

BC3

As part of Windows 10 OS it does it’s own branch Cache while downloading updates and it will overwrite SCCM client settings. To disable this setting we can create a group policy and apply just to windows 10 OS’s.

Below is the location of the settings that need to be disabled

Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ Delivery Optimization, set (Download Mode) to disabled BC5

If the policy is not showing it is probable because the ADMX template for windows 10 has not been added.

The last part is to enable Branch Cache in SCCM for the distribution points by selecting the properties of the distribution point as given below. BC4

To test that the policy has been applied go to a client device and update the machine policy. Then run netsh command again and we should now see branch cache has been enabled.

netsh branchcache show status all BC7