Copy WSUS approvals between Groups

Posted on by

source: http://www.craig-tolley.co.uk/2016/01/21/wsus-copy-updates-between-groups/

Run the script below, then call it using the following syntax:

Copy-WsusGroupApprovals -WsusServerFqdn wsus.domain.co.uk -SourceGroupName "OldServers" -TargetGroupName "NewServers"

You can optionally specify a port, the default being 8530. You can also specify to use a secure connection. The group names are both case sensitive though.

# ----------------------------------------------------------------------------------------------------------
# PURPOSE:    WSUS - Copy Approvals from one Group to another Group
#
# VERSION     DATE         USER                DETAILS
# 1           21/01/2016   Craig Tolley        First Version
#
# ----------------------------------------------------------------------------------------------------------

#.SYNOPSIS
# Copies all approvals from the specified source group to the specified destination group. 
# Group names are case sensitive. 
# Unless specified the default WSUS port of 8530 will be used to connect. 
function Copy-WsusGroupApprovals
{
    param
    (

    [Parameter(Mandatory=$true)]
    [ValidateNotNullOrEmpty()]
    [String]$WsusServerFqdn,

    [Int]$WsusServerPort = 8530,

    [Boolean]$WsusServerSecureConnect = $false,

    [Parameter(Mandatory=$true)]
    [ValidateNotNullOrEmpty()]
    [String]$SourceGroupName,

    [Parameter(Mandatory=$true)]
    [ValidateNotNullOrEmpty()]
    [String]$TargetGroupName

    )
    
    # Load the assembly required
    try
    {
        [void][reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration")
    }
    catch
    {
        Write-Error "Unable to load the Microsoft.UpdateServices.Administration assembly: $($_.Exception.Message)"
        break

    }

    # Attempt the connection to the WSUS Server
    try
    {
        $WsusServer = [Microsoft.UpdateServices.Administration.AdminProxy]::getUpdateServer($WsusServerFqdn, $WsusServerSecureConnect, $WsusServerPort)
    }
    catch
    {
        Write-Error "Unable to connect to the WSUS Server: $($_.Exception.Message)"
        break
    }

    # Get all of the Wsus Groups, and check that the specified source and destination groups exist
    $Groups = $WsusServer.GetComputerTargetGroups()
    If ($Groups.Name -notcontains $SourceGroupName -or $Groups.Name -notcontains $TargetGroupName)
    {
        Write-Error "Source or Destination group names cannot be found in the list of groups on the WSUS Server. Group names are case sensitive. Please check your names."
        break
    }
    $SourceGroupObj = $Groups | Where {$_.Name -eq $SourceGroupName}
    $TargetGroupObj = $Groups | Where {$_.Name -eq $TargetGroupName}

    # Get all of the updates on the server
    Write-Progress -Activity "Getting Details of all updates"
    $Updates = $WsusServer.GetUpdates()
    
    # Go through each of the updates. If the update has an approval for the source group, then create an approval for the destination group. 
    $i = 0
    $Approved = 0
    ForEach ($Update in $Updates)
    {
        $i ++
        Write-Progress -Activity "Copying update approvals" -PercentComplete (($i/$($Updates.Count))*100) -Status "$i of $($Updates.Count)"
        
        if ($Update.GetUpdateApprovals($SourceGroupObj).Count -ne 0 -and $Update.GetUpdateApprovals($TargetGroupObj).Count -eq 0)
        {
            Write-Host ("Approving {0} for {1}" -f $Update.Title, $TargetGroupObj.Name)
            $Update.Approve('Install',$TargetGroupObj) | Out-Null
            $Approved ++
        }
    }
    Write-Progress -Activity "Copying update approvals" -Completed

   Write-Output ("Approved {0} updates for target group {1}" -f $Approved, $TargetGroupName)
}

Enable CBT on VMware

Posted on by

See also http://www.bvanleeuwen.nl/faq/?p=1236

Create vm list

$targets = Get-VM | Select Name, @{N="CBT";E={(Get-View $_).Config.ChangeTrackingEnabled}} | WHERE {$_.CBT -like "False"}

Enable CBT

ForEach ($target in $targets) {
   $vm = $target.Name
   $vmView = Get-vm $vm | get-view
   $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
   $vmConfigSpec.changeTrackingEnabled = $true
   $vmView.reconfigVM($vmConfigSpec)
}

Create/Remove snapshot to enable CBT

ForEach ($target in $targets) {
   $vm = $target.Name
   Get-VM $vm | Get-Snapshot | Remove-Snapshot -confirm:$false
   New-Snapshot -VM (Get-VM $vm ) -Name "CBTSnap"
   Get-VM $vm | Get-Snapshot -Name "CBTSnap" | Remove-Snapshot -confirm:$false
}

 

Update a HA Netscaler environment

Posted on by

source:http://support.citrix.com/article/CTX127455

To update an HA netscaler, do the following steps.

User-added image

Upgrade the secondary netscaler appliance

    1. Save the config: save config
    2. Switch to shell: shell
    3. Change to the installation directory: cd /var/nsinstall
    4. Create a temporary directory: mkdir x.xnsinstall
    5. Chang to the created directory: cd x.xnsinstall
    6. Upload the files to the temporary directory (e.g. pscp build-11.0-66.11_nc.tgz nsroot@192.168.1.1:/var/nsinstall/11.0nsinstall/build-11.0-66.11_nc.tgz)
    7. Extract the files: tar -zxvf ns-x.0-xx.x-doc.tgz
    8. Install the software: # ./installns
    9. Press y to restart the appliance
    10. Check the state of the appliance: > show ha node
      This should state that it is the secondary node and synchronization is disabled. To disable the synchronization manually run the command: > set node -hasync disable
    11. Check the configuration
      The version can be found with the command:  > show version
    12. Failover the appliance: > force failover

Upgrade the primary netscaler appliance

  1. Follow step 1 to 9 mentioned in the previous section
  2. Check if the appliance is UP and it is the primary node: > show ha node
    If the appliance isn’t the primary application a failover can be initiated: > force failover

Enable Synchronization

  1. Log on the secondary node, check if it is the secondary node: > show node
  2. Enable synchronization: > set node -hasync enable
  3. Check synchronization status: > show ns runningconfig

The update has been completed. Additional backups can be removed as well the downloaded files in the created directory (step 4).

Disable all active users from an AD group

Posted on by

To disable all enabled users from an Active Directory group use the following script. Replace the groupname with the correct groupname. Also this script will show what it does, but does not disable the accounts until you remove the “-whatif” option from the command: Disable-ADAccount -Identity $user -whatif

 

The original script comes from https://community.spiceworks.com/topic/380100-disable-enable-ad-account-based-on-group-membership

 

$Group = "groupname"
Try { Import-Module ActiveDirectory -ErrorAction Stop }
Catch { Write-Host "Unable to load Active Directory module, is RSAT installed?"; Exit }

Try {
    $GroupDN = (Get-ADGroup $Group -ErrorAction Stop).DistinguishedName
}
Catch {
    Write-Host "Unable to locate group: $Group because ""$($Error[0])""" -ForegroundColor Red
    Exit
}

ForEach ($User in (Get-ADUser -Filter * -Properties MemberOf))
{   If ($User.MemberOf -contains $GroupDN)
    {   
        If ($user.enabled)
        {
            Write-Host "Disabling $($User.Name)"
            Disable-ADAccount -Identity $user -whatif
        }
    }
}

 

Check last logged on date from user

Posted on by

Check the last logged on date for users. Fill in the correct filter (e.g. Name, Office) and the name of it (e.g. joe*

 

Import-Module ActiveDirectory

function Get-ADUserLastLogon([string]$userName)
{
  $dcs = Get-ADDomainController -Filter {Name -like "*"}
  $time = 0
  foreach($dc in $dcs)
  { 
    $hostname = $dc.HostName
    $user = Get-ADUser $userName | Get-ADObject -Properties lastLogon 
    if($user.LastLogon -gt $time) 
    {
      $time = $user.LastLogon
    }
  }
  $dt = [DateTime]::FromFileTime($time)
  Write-Host $username "last logged on at:" $dt }


foreach ($user in Get-ADUser -Filter 'Name -like "*joe*"' -Properties *) {
    Get-ADUserLastLogon -UserName $user
    }

 

Implementing Content Freshness protection in DFSR

Posted on by

https://blogs.technet.microsoft.com/askds/2009/11/18/implementing-content-freshness-protection-in-dfsr/

 

Background

Content Freshness is an admin-defined setting that you can set on a per-computer basis when using DFSR on Win2008 or Win2008 R2 – it does not exist on Windows Server 2003 R2. The DFSR database has a record for each Replicated Folder (RF) called CONTENT_SET_RECORD. This record contains a timestamp called “LastConnected”. We store this record on a per-Replicated-Folder basis because it’s possible for a replicated folder to be current when it’s connected to other members in that replication group. At the same time, another replicated folder can be stale because it is not connected with other members in its replication group. Every day, DFSR updates this timestamp to show the opportunity for replication occurred. When attempting replication for an RF between computers, the DFSR service checks if the last time replication was allowed is older than the freshness date. If the last-allowed-replicated date is newer, it replicates. If it’s not, we block replication.

By now, you’re asking yourself “why would I want to block replication.” Good question. DFSR has a JET database just like Active Directory, and it uses multi-master replication just like AD. This means that it must implement tombstones to deleted items to replicate. When a file is deleted in DFSR, the local database records the deletion as a tombstone in the database – a logical deletion. After 60 days DFSR garbage collects the record from the database and it is truly gone – a physical deletion. Online defragmentation of the database can now reclaim that whitespace. The 60 days allows all the replication partners to learn about the deletion and act on it.

And herein lays the problem. If a DFSR server cannot replicate an RF for more than 60 days, but then replication is allowed later, it can replicate out old deletions for files that are actually live or replicate out stale data and overwrite existing files. If you’ve ever worked on an Active Directory “lingering object” issue, you have seen what can happen when a DC that was offline for months is brought back up. This is why Strict Replication Consistency was invented for AD – Content Freshness protection is the same thing.

Being “unable to replicate” can mean any one of these scenarios:

  • Disabling the replication connections.
  • Deleting the replication connections (either one-way or in both directions).
  • Stopping the DFSR service.
  • Closing the schedule (i.e. setting “no replication”)
  • Keeping the server shut off.

This whole content freshness idea is novel enough that we went to the trouble of applying for a patent on it.

Implementing Content Freshness Protection

Content Freshness protection is not enabled by default. To turn it on you simply modify the DfsrMachineConfig setting for MaxOfflineTimeInDays on each DFSR server with:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=<some value>

The recommendation is to set the value to 60:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60

Remember, this has to be done on all DFSR servers, as this change only affects the computer itself. This value is not stored in a central AD location, but instead in the DfsrMachineConfig.XML file that resides in the hidden operating system folder “%systemdrive%\system volume information\dfsr\config”:

image

You can also view your existing MaxOfflineTimeInDays with:

wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

Remember, by default this protection is OFF and be assumed to be zero if there are no entries in the DfsrMachineConfig.xml.

Note: Sharp-eyed admins may notice that we actually have an AD attribute stamped on every Replication Group called ms-DFSR-TombstoneExpiryInMin that appears to control tombstone lifetime. It even has the value – in minutes – for 60 days. Sorry to disappoint you, but this attribute is never read by DFSR and changing it has no effect – tombstone lifetime garbage collection is always hard-coded to 60 days in the service and cannot be changed.

Protection in Action

Let’s see how all this works. My repro environment:

  • A pair of Windows Server 2008 R2 computers named 2008r2-fresh-01 and 2008r2-fresh-02
  • Replicating in a Replication Group named “RG1”
  • Using a Replicated Folder named “RF1”
  • Keeping a few user files in sync.
  • MaxOfflineTimeInDays set to 60 on 2008r2-fresh-02

Important note: I am going to simulate the offline time by rolling clocks forward. Never ever do this in production – this is for testing and demonstration purposes only. Also, I only set MaxOfflineTimeInDays on one server – you would do this on all servers.

So here’s my data:

image

Now I stop DFSR on 2008r2-fresh-02 and roll time forward to January 1st, 2010 on both servers – about 75 days from this writing. I then make a few changes on 2008r2-fresh-02.

image

And then I start the DFSR service back up on 2008r2-fresh-02.

  • My changed files do not replicate out
  • New files do not replicate in

I now have this event:

Log Name:      DFS Replication
Source:        DFSR
Date:          1/1/2010 3:37:14 PM
Event ID:      4012
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      2008r2-fresh-02.blueyonderairlines.com
Description:
The DFS Replication service stopped replication on the replicated folder at local path c:\rf1. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter. Because of this, DFS Replication considers this data to be stale, and will replace it with data from other members of the replication group during the next replication. DFS Replication will move the stale files to the local Conflict folder. No user action is required.
Additional Information:
Error: 9061 (The replicated folder has been offline for too long.)
Replicated Folder Name: rf1
Replicated Folder ID: 5856C18F-CA72-4D2D-9D89-4CC1D8042D86
Replication Group Name: rg1
Replication Group ID: BC5976EF-997E-4149-819D-57193F21EC76
Member ID: FAEC4B17-E81F-4036-AAD9-78AA46814606

Note: this event has incorrect wording. The first two sentences in the description are good, but the following sentences are wrong. DFSR does not self-correct this situation, it does not move files into the ConflictAndDeleted folder, and you, the user, have actions you need to take. More on this later.

The DFSR Debug logs will show (edited for brevity):

20100101 15:37:14.410 1008 CSMG 5504 [WARN] ContentSetManager::CheckContentSetState This replicated folder has not connected to other partners for a long time. lastOnlineTime: [*** Logger Runtime Error:-114757888 ***]

20100101 15:37:14.410 1008 CSMG 7492 [ERROR] ContentSetManager::Initialize Failed to initialize ContentSetManager csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 Error:

+ [Error:9061(0x2365) ContentSetManager::CheckContentSetState contentsetmanager.cpp:5596 1008 C The replicated folder has been offline for too long.]

20100101 15:37:14.410 1008 CSMG 7972 ContentSetManager::Run csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} csName:rf1 state:InitialBuilding

20100101 15:37:14.504 1948 SRTR 957 [WARN] SERVER_EstablishSession Failed to establish a replicated folder session. connId:{5E05AE2A-6117-4206-B745-7785DB316F74} csId:{5856C18F-CA72-4D2D-9D89-4CC1D8042D86} Error:

+ [Error:9028(0x2344) UpstreamTransport::EstablishSession upstreamtransport.cpp:808 1948 C The content set was not found]

The state of the replicated folder will be “In Error” – i.e. set to 5:

wmic.exe /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get ReplicationGroupName,ReplicatedFolderName,State

ReplicatedFolderName   ReplicationGroupName   State
rf1                               rg1                               5

The above is Content Freshness protection in action. It is protecting your DFSR environment from sending divergent data out to the rest of your working servers.

Recovering DFSR from Content Protection

Important note: Before repairing the blocked replication, get a backup of the data on the affected server and its partners. Failure to do will tempt Murphy’s Law to disastrous new heights. Understand that by following these steps below, any DFSR data that was on this server and never replicated will be moved to PreExisting and/or ConflictAndDeleted – this server goes through non-authoritative sync again and loses all conflicts with other DFSR servers. You have been warned!!!

Also, whatever is being done to stop replication from working needs to be ironed out – whether it is leaving the service off for months on end or not having any connections. Otherwise this is just going to happen again.

To get things back in order, do the following:

1. Start DFSMGMT.MSC on the affected server.

2. On any affected replication groups this server is a member of, select the computer on the Membership tab and “Disable” it.

image

3. Accept the warning prompt.

image

4. If the reason for replication never occurring was the schedule being set to “no replication” on the RG or RF, or no bi-directional connections being place between servers, fix that situation now.

5. Force AD Replication and verify it has converged.

6. On the affected server, run:

DFSRDIAG.EXE POLLAD

7. Wait for the 4008 and 4114 events being written to the DFSR event log to confirm that the replicated folder(s) are no longer being replicated.

8. In DFSMGMT.MSC, “Enable” the replication again on the affected replicated folders for that server.

9. Force AD replication and POLLAD again.

The server goes through non-authoritative initial sync, as if it was setup the first time. All matching data is unchanged and does not replicate. Any files on the server that do not exist on its authoritative partner are moved to the PreExisting folder. Any files on the server that have been changed locally are moved to the ConflictAndDeleted folder and the authoritative server’s copy is replicated inbound.

The Sum Up

Content Freshness protection is a good thing and putting it in place may someday save you some real pain. Trust me – we work cases here where Content Freshness being enabled would have stopped huge problems. All it takes is Windows Server 2008 or later, and a few moments of your time.

– Ned “Kool and the Gang” Pyle

sqlservr (4016) An attempt to open the file “C:\windows\system32\LogFiles\Sum\Api.chk” for read / write access failed with system error 5 (0x00000005): “Access is denied. “. The open file operation will fail with error -1032 (0xfffffbf8).

Posted on by

https://support.microsoft.com/en-us/kb/2811566

 

Symptoms

Consider the following scenario:

  • You install Microsoft SQL Server 2012 or SQL Server 2012 Analysis Services on a computer that is running Windows Server 2012.
  • You use the default account as a service account for these applications during the installation.
  • The installation is successful.
  • After the installation, the services for these programs start successfully.

In this scenario, you may find error messages in the Application log that resemble the following:

For instances of SQL Server (SQLServr.exe)

sqlservr (3472) An attempt to open the file “C:\Windows\system32\LogFiles\Sum\Api.log” for read only access failed with system error 5 (0x00000005): “Access is denied. “. The open file operation will fail with error -1032 (0xfffffbf8).
sqlservr (3472) Error -1032 (0xfffffbf8) occurred while opening logfile C:\Windows\system32\LogFiles\Sum\Api.log.

For instances of SQL Server Analysis Services (Msmdsrv.exe)

msmdsrv (4680) An attempt to open the file “C:\Windows\system32\LogFiles\Sum\Api.chk” for read / write access failed with system error 5 (0x00000005): “Access is denied. “. The open file operation will fail with error -1032 (0xfffffbf8).

msmdsrv (4680) Error -1032 (0xfffffbf8) occurred while opening logfile C:\Windows\system32\LogFiles\Sum\Api.log.

Cause

This problem occurs because of insufficient permissions for the service startup accounts for SQL Server and for SQL Server Analysis Services when the services access the following folder for logging as a part of the Software Usage Metrics feature:

C:\Windows\System32\LogFiles\Sum
Workaround

To work around this problem, add read/write permissions manually to the service accounts that are used by SQL Server (sqlservr.exe) and SQL Server Analysis Services (msmdsrv.exe) to access the \Windows\System32\LogFiles\Sum folder.

Configuring disks to use VMware Paravirtual SCSI (PVSCSI) adapters

Posted on by

source: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010398

Details

This article includes supplemental information about configuring and using VMware Paravirtual SCSI (PVSCSI) adapters.

PVSCSI adapters are high-performance storage adapters that can result in greater throughput and lower CPU utilization. PVSCSI adapters are best suited for environments, especially SAN environments, where hardware or applications drive a very high amount of I/O throughput. The VMware PVSCSI adapter driver is also compatible with the Windows Storport storage driver. PVSCSI adapters are not suited for DAS environments.

 

This table shows the support matrix for use of Paravirtual SCSI adapters for data disks and boot disks for the various guest operating systems and ESX versions. Support shown in the table is from the listed ESXi/ESX version and later versions.

Guest operating system Data Disk Boot Disk
Windows Server 2012 R2 (64 bit only) ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5
Windows Server 2012 (64 bit only) ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5
Windows Server 2008 R2 (64 bit only) ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x
Windows Server 2008 (32 and 64 bit) ESXi/ESX 4.x, ESXi 5.x ESXi/ESX 4.0 Update 1, ESXi/ESX 4.1, ESXi 5.x
Windows Server 2003 (32 and 64 bit) ESXi/ESX 4.x, ESXi 5.x ESXi/ESX 4.x, ESXi 5.x
Windows 8.1 (32 and 64 bit) ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 2, ESXi 5.1, ESXi 5.5
Windows 8 (32 and 64 bit) ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5 ESXi 5.0 Update 1, ESXi 5.1, ESXi 5.5
Windows 7 (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
Windows Vista (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
Windows XP (32 and 64 bit) ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.1, ESXi 5.x
CentOS 5.x (32 and 64 bit) ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x Not Supported
CentOS 6.x (32 and 64 bit) * ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x ESXi/ESX 4.0 Update 4, ESXi/ESX 4.1 Update 2, ESXi 5.x
CentOS 7.x (64 bit) ESXi 5.5 ESXi 5.5
Red Hat Enterprise Linux (RHEL) 5 (32 and 64 bit) and all update releases ESXi/ESX 4.x, ESXi 5.x Not Supported
RHEL 6 (32 and 64 bit) ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x
RHEL 7 (64 bit) ESXi 5.5 ESXi 5.5
SUSE Linux Enterprise 11 SP1(32 and 64 bit) and later releases ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x
Ubuntu 10.04 (32 and 64 bit) and later releases ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x ESXi/ESX 4.0 Update 2, ESXi/ESX 4.1, ESXi 5.x

 

 

* = CentOS 6.5 is not supported on ESXi/ESX 4.0. Support added in ESXi/ESX 4.1 Update 3, ESXi 5.0 Update 2 and above only.

The default type of newly hot-added SCSI adapter depends on the type of primary (boot) SCSI controller. This means that hot-adding a PVSCSI adapter is only supported for those versions that support booting from a PVSCSI adapter.

Paravirtual SCSI adapters also have these limitations:

  • Hot add or hot remove requires a bus rescan from within the guest.
  • Disks with snapshots might not experience performance gains when used on Paravirtual SCSI adapters if memory on the ESX host is over committed.
  • Do not use PVSCSI on a virtual machine running Windows with spanned volumes. Data may become inaccessible to the guest operating system.
  • If you upgrade from RHEL 5 to an unsupported kernel, you might not be able to access data on the virtual machine’s PVSCSI disks. You can run vmware-config-tools.pl with the kernel-version parameter to regain access.

Solution

To configure a new or existing data disk to use a PVSCSI adapter:

  1. Launch a vSphere Client and log in to an ESXi/ESX host or vCenter Server.
  2. Select a virtual machine, or create a new one.
  3. Ensure a guest operating system that supports PVSCSI is installed on the virtual machine.
  4. If it is an existing virtual machine, power it off.
  5. In the vSphere Client, right-click on the virtual machine and click Edit Settings.
  6. Click the Hardware tab.
  7. Click Add.
  8. Select Hard Disk.
  9. Click Next.
  10. Choose any one of the available options.
  11. Click Next.
  12. Specify the options you require. Options vary depending on which type of disk you chose.
  13. Choose a Virtual DeviceNode and specify whether you want to use Independent mode. For data disks, choose a Virtual Device Nodebetween SCSI (1:0)to SCSI (3:15). For a boot disk, choose Virtual Device Node SCSI (0:0), or choose the Virtual Device Node that boots in the order you require.
    Note: To set a disk to use Independent mode there must be no snapshots associated to the virtual disk, if there are existing snapshots commit them before changing the disk type.
  14. Click Next.
  15. Click Finish to finish the process and exit the Add Hardware wizard. A new disk and controller are created.
  16. Select the newly created controller and click Change Type.
  17. Click VMware Paravirtual and click OK.
  18. Click OK to exit the Virtual Machine Properties dialog.
  19. Power on the virtual machine.
  20. Install VMware Tools. VMware Tools includes the PVSCSI driver.
  21. If it is a new virtual disk, scan and format the hard disk within the guest operating system.

To configure an existing Windows boot disk to use a PVSCSI adapter:
This procedure is required as the guest operating system does not have the PVSCSI driver and the guest will BSOD on boot if using the above method. This workaround forces the guest operating system to install the PVSCSI driver.

  1. Power off the virtual machine.
  2. Create a new temporary 1GB disk(SCSI 1:0) and assign a new SCSI controller (default is LSI LOGIC SAS).
  3. Change the new SCSI controller to PVSCSI for the new SCSI controller.
  4. Click Change Type.
  5. Click VMware Paravirtual and click OK.
  6. Click OK to exit the Virtual Machine Properties dialog.
  7. Power on the virtual machine.
  8. Verify the new disk was found and is visible in Disk Management. This confirms the PVSCSI driver is now installed.
  9. Power off the virtual machine.
  10. Delete the temporary 1GB vmdk disk and associated controller (SCSI 1:0).
  11. Change the original SCSI controller(SCSI 0:X) to PVSCSI as detailed in Steps 3 to 5.
  12. Power on the virtual machine.

To deploy and boot a new Windows virtual machine from a disk attached to a PVSCSI adapter, the VMware PVSCSI driver must be installed in the Windows guest. Floppy disk images that contain the driver are available for the versions of ESXi/ESX that support this. The required floppy images are stored on the host and are located at the /vmimages/floppies/ directory. If the floppy images are not visible, see Unable to mount a floppy image in vCenter Server (1036836).

To install PVSCSI drivers:
Note: This procedure assumes that your virtual machine does not have a floppy driver. If the virtual machine already has a floppy drive, skip directly to Step 6.

  1. Right-click the virtual machine and click Edit Settings.
  2. Click Add.
  3. From list, click Floppy Drive and click Next.
  4. Click Next to accept the default option.
  5. Click Finish.
  6. Click New Floppy or Floppy Drive.
  7. Select the Use existing floppy image in datastore option.
  8. Click Browse.
  9. Navigate to the vmimages or floppies folder.
  10. Select the image and click Open. Note: When installing Windows 2012 Server, use the Windows 2008 image pvscsi-Windows2008.flp to install the driver.
  11. Click OK.
  12. Boot the virtual machine to install the PVSCSI drivers.

 

Using the BurFlags registry key to reinitialize File Replication Service replica sets

Posted on by

https://support.microsoft.com/en-us/kb/290762

 

Restoring FRS replicas

The global BurFlags registry key contains REG_DWORD values, and is located in the following location in the registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

The most common values for the BurFlags registry key are:

  • D2, also known as a nonauthoritative mode restore
  • D4, also known as an authoritative mode restore

You can also perform BurFlags restores at the same time as you restore data from backup or from any other known good source, and then restart the service.

Nonauthoritative restore

Nonauthoritative restores are the most common way to reinitialize individual members of FRS replica sets that are having difficulty. These difficulties may include:

  • Assertions in the FRS service
  • Corruption of the local jet database
  • Journal wrap errors
  • FRS replication failures

Attempt nonauthoritative restores only after you discover FRS dependencies and you understand and resolve the root cause. For more information about how to discover FRS dependencies, see the “Considerations before configuring authoritative or nonauthoritative restores of FRS members” section later in this article.

Members who are nonauthoritatively restored must have inbound connections from operational upstream partners where you are performing Active Directory and FRS replication. In a large replica set that has at least one known good replica member, you can recover all the remaining replica members by using a nonauthoritative mode restore if you reinitialize the computers in direct replication partner order.

If you determine that you must complete a nonauthoritative restore to return a member back into service, save as much state from that member and from the direct replication partner in the direction that replication is not working. This permits you to review the problem later. You can obtain state information from the FRS and System logs in the Event Viewer.

Note You can configure the FRS logs to record detailed debugging entries. For more information about how to configure FRS logging, click the following article number to view the article in the Microsoft Knowledge Base:

221111 Description of FRS entries in the registry

To perform a nonauthoritative restore, stop the FRS service, configure the

BurFlags

registry key, and then restart the FRS service. To do so:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. Locate the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  7. In the right pane, double-click BurFlags.
  8. In the Edit DWORD Value dialog box, type D2 and then click OK.
  9. Quit Registry Editor, and then switch to the Command box.
  10. In the Command box, type net start ntfrs.
  11. Quit the Command box.

When the FRS service restarts, the following actions occur:

  • The value for BurFlags registry key returns to 0.
  • Files in the reinitialized FRS folders are moved to a Pre-existing folder.
  • An event 13565 is logged to signal that a nonauthoritative restore is started.
  • The FRS database is rebuilt.
  • The member performs an initial join of the replica set from an upstream partner or from the computer that is specified in the Replica Set Parent registry key if a parent has been specified for SYSVOL replica sets.
  • The reinitialized computer runs a full replication of the affected replica sets when the relevant replication schedule begins.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

Note: The placement of files in the Pre-existing folder on reinitialized members is a safeguard in FRS designed to prevent accidental data loss. Any files destined for the replica that exist only in the local Pre-existing folder and did not replicate in after the initial replication may then be copied to the appropriate folder. When outbound replication has occurred, delete files in the Pre-existing folder to free up additional drive space.

Authoritative FRS restore

Use authoritative restores only as a final option, such as in the case of directory collisions.

For example, you may require an authoritative restore if you must recover an FRS replica set where replication has completely stopped and requires a rebuild from scratch.

The following list of requirements must be met when before you perform an authoritative FRS restore:

  1. The FRS service must be disabled on all downstream partners (direct and transitive) for the reinitialized replica sets before you restart the FRS service when the authoritative restore has been configured to occur.
  2. Events 13553 and 13516 have been logged in the FRS event log. These events indicate that the membership to the replica set has been established on the computer that is configured for the authoritative restore.
  3. The computer that is configured for the authoritative restore is configured to be authoritative for all the data that you want to replicate to replica set members. This is not the case if you are performing a join on an empty directory. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
    266679 Pre-staging the File Replication service replicated files on SYSVOL and Distributed file system shares for optimal synchronization
  4. All other partners in the replica set must be reinitialized with a nonauthoritative restore.

To complete an authoritative restore, stop the FRS service, configure the

BurFlags

registry key, and then restart the FRS service. To do so:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. Locate the following subkey in the registry:
    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
  7. In the right pane, double click BurFlags.
  8. In the Edit DWORD Value dialog box, type D4 and then click OK.
  9. Quit Registry Editor, and then switch to the Command box.
  10. In the Command box, type net start ntfrs.
  11. Quit the Command box.

When the FRS service is restarted, the following actions occur:

  • The value for the BurFlags registry key is set back to 0.
  • An event 13566 is logged to signal that an authoritative restore is started.
  • Files in the reinitialized FRS replicated directories remain unchanged and become authoritative on direct replication. Additionally, the files become indirect replication partners through transitive replication.
  • The FRS database is rebuilt based on current file inventory.
  • When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.

Global vs. replica set specific reinitialization

There are both global- and replica set-specific BurFlags registry keys. Setting the global BurFlags registry key reinitializes all replica sets that the member holds. Do this only when the computer holds only one replica set, or when the replica sets that it holds are relatively small.

In contrast to configuring the global BurFlags key, the replica set BurFlags key permits you to reinitializes discrete, individual replica sets, allowing healthy replication sets to be left intact.

The global BurFlags registry key is found in the following location in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup / Restore\Process At Startup

This key can contain the same values as those that are discussed earlier in this article for authoritative and nonauthoritative restores.

You can locate the replica set specific BurFlags registry key by determining the GUID for the replica set that you want to configure. To determine which GUID corresponds to which replica set and configure a restore, follow these steps:

  1. Click Start, and then click Run.
  2. In the Open box, type cmd and then press ENTER.
  3. In the Command box, type net stop ntfrs.
  4. Click Start, and then click Run.
  5. In the Open box, type regedit and then press ENTER.
  6. To determine the GUID that represents the replica set that you want to configure, follow these steps:
    1. Locate the following key in the registry:
      KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets
    2. Below the Replica Sets subkey, there are one or more subkeys that are identified by a GUID. In the left pane, click the GUID, and then in the right pane note the Data that is listed for the Replica Set Root value. This file system path will indicate which replica set is represented by this GUID.
    3. Repeat step 4 for each GUID that is listed below the Replica Sets subkey until you locate the replica set that you want to configure. Note the GUID.
  7. Locate the following key in the registry:
    KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets
  8. Below the Cumulative Replica Sets subkey, locate the GUID you noted in step 6c.
  9. In the right pane, double click BurFlags.
  10. In the Edit DWORD Value dialog box, type D2 to complete a nonauthoritative restore or type D4 to complete an authoritative restore, and then click OK.
  11. Quit Registry Editor, and then switch to the Command box.
  12. In the Command box, type net start ntfrs.
  13. Quit the Command box.

Considerations before you configure authoritative or nonauthoritative restores of FRS members

If you configure an FRS member to complete an authoritative or nonauthoritative restore by using the BurFlags registry subkey, you do not resolve the issues that initially caused the replication problem. If you cannot determine the cause of the replication difficulties, the members will typically revert back to the problematic situation as replication continues.

A detailed breakdown on FRS interdependencies is beyond the scope of this article, but your troubleshooting should include the following actions:

  • Verify that Active Directory replication is successful. Resolve Active Directory replication issues before you perform additional FRS troubleshooting. Use the Repadmin /showreps command to verify that Active Directory replication is occurring successfully. The Repadmin.exe tool is located in the Support\Tools folder on the Windows 2000 CD-ROM.
  • Verify that inbound and outbound Active Directory replication occurs between all domain controllers that host SYSVOL replica sets and between all domain controllers that host computer accounts for servers that participate in DFS replica sets.
  • Verify that FRS member objects, subscriber objects and connection objects exist in the Active Directory for all the computers that participate in FRS replication.
  • Verify that inbound and outbound connection objects exist for all domain controllers in the domain for SYSVOL replica sets.
  • Verify that all the members of DFS replica sets have at least inbound connection objects in a topology to avoid islands of replication.
  • Review the FRS and SYSTEM event logs on direct replication partners that are having difficulty.
  • Review the FRS debug logs in the %SYSTEMROOT%\DEBUG\NTFRS_*.LOG between the direct replication partners that are having replication problems.