Windows

DFSR Failure After VM Restore (DFSR Error 2104)

Posted on Updated on

Reading Time: 3 minutes

I have an environment that heavily leverages DFS, and recently one of the replication member servers had to be restored from a VEEAM backup. Typically VEEAM is great and doesn’t cause any issues, in this case though DFS completely broke. I got a TON of SCOM alerts, and the event log was littered with them as well.

The DFS Replication service failed to recover from an internal database error on volume D:. Replication has been stopped for all replicated folders on this volume. Additional Information: Error: 9214 (Internal database error (-1605)) Volume: D: xxxxxx Database: D:\System Volume Information\DFSR

 

Event 2212, DFSR 

The DFS Replication service has detected an unexpected shutdown on volume D:. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. The service has automatically initiated a recovery process. The service will rebuild the database if it determines it cannot reliably recover. No user action is required.

Additional Information:
Volume: D:
GUID: xxxxxxxxxxxxxxx

 

Error 2104, DFSR 

The DFS Replication service failed to recover from an internal database error on volume D:. Replication has been stopped for all replicated folders on this volume.

Additional Information:
Error: 9214 (Internal database error (-1605))
Volume: xxxxxxxxxxxxxxxxxxxxxxxx
Database: D:\System Volume Information\DFSR

 

The important error here is 2104, noting the database issue. There are multiple topics out there that talk about this, but they all end up linking back to this support article.

 https://support.microsoft.com/en-us/help/2517913/distributed-file-system-replication-dfsr-no-longer-replicates-files-af

 

In the end, essentially the database that is used by DFS replication becomes corrupted. It is a system-generated database so all you need to do is disable the replication service, delete the database, and start the replication service back up. Easy? No. There are a myriad of issues with doing this, mostly because the database is hosted in “System Volume Information” on the volume that hosts the DFS Root folder, or wherever you’ve placed the replication targets. Luckily for you, I hit my head against a wall for hours on end and figured out the solution.

Step 1: Stop DFSR service (stop-service DFSR)

Step 2: Grant yourself visibility to the “System Volume Information” folder. This entails flipping the radio button in explorer to “view hidden files”, as well as unchecking the box for “hide all system protected folders”.

Step 3: Grant yourself proper permissions to the “System Volume Information” folder. Go to the root of the volume that holds the replication targets eg. D:\. You will now see a grayed-out folder with a lock on it called “System Volume Information”. Go through the normal rigamaroo to grant “Administrators” full control over the folder. You should then be able to open it up, before it would have said “Access Denied”.

Step 4: Delete or rename the “DFSR” folder inside “System Volume Information”. Unfortunately, that’s not easy. Based on what I saw, it was because the file names in the database folder exceeded the limitations of explorer ( https://hansencloud.com/2014/04/22/varying-file-name-too-long-issues ). Here the easiest thing to use is the wonderful Robocopy /MIR! Create an empty folder in the root of the drive and copy it into the DFSR folder using the /mir flag in robocopy. This will “mirror” the source folder into the destination folder.

Now the DFSR folder should be completely empty.

 

Step 5: Start the DFS Replication service (start-service DFSR)

Step 6: Check for validating event logs.

Event 4102, DFSR 

The DFS Replication service initialized the replicated folder at local path D:\xxxxxx and is waiting to perform initial replication. The replicated folder will remain in this state until it has received replicated data, directly or indirectly, from the designated primary member.

Additional Information:
Replicated Folder Name: XXXXXXX
Replicated Folder ID: XXXXXXXXXXXXXXXXXXXX 
Replication Group Name: XXXXX\XXXX 
Replication Group ID: XXXXXXXXXX
Member ID: XXXXXXXXXXXXX

 

Event 4412, DFSR

The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.

Additional Information:
Original File Path: D:\XXXXXXX
New Name in Conflict Folder: XXXXXXXXXXX
Replicated Folder Root: D:\XXXXXXXX
File ID: XXXXXXXXXXXXXXXX
Replicated Folder Name: XXXXXXXXXXXX
Replicated Folder ID: XXXXXXXXXXXXXXX
Replication Group Name: XXXXXXXXXXXXXX
Replication Group ID: XXXXXXXXXXXXXXXXX
Member ID: XXXXXXXXXXXXXXXXXXXX

 

 

There you go! You’ve done it! Microsoft said you had to contact their support to fix it, but you crafty devil – you’ve gone and done it yourself.

I hope I’ve made your day at least a little bit easier.

Configure Server Core for IIS Remote Management

Posted on

Reading Time: 3 minutes

Everyone’s familiar by now with reasons why you want to use Server Core Edition for things like IIS, DNS, etc. In a recent project I found an interesting scenario where my GUI management server couldn’t connect remotely to the IIS instance that I was running on Server 2016 Core. There are a few oddities, so I decided to blog about it – let’s get going.

TL;DR steps are as follows:

  • Install IIS Web Role
  • Install IIS Management Feature
  • Change Registry Setting for Remote Management
  • Set Management Service to start automatically
  • Connect
  • Work
  • Get a promotion
  • Get a raise
  • Get a boat

Maybe not the boat, but that’s the dream right? Anyways, here’s the nitty gritty.

 

First, we need to see if IIS is installed. Assumedly because you’re already trying to figure out how to connect to it you’ve already done this. It’s good to check anyways, just to be sure. Note that in server core it first drops you into a cmd shell. This is 2017 and everything is done in powershell now, so go ahead and launch yourself into a PS shell. Then, we’ll check if the feature is installed by running the following command

Get-WindowsFeature | Where-Object {$_.DisplayName -eq “Web Server (IIS)”}

 

Here we can see that IIS is in fact not installed, so let’s go ahead and fix that. While we install IIS, it’s also important to install the IIS Remote Management Feature as well. Otherwise, there will be no connecting remotely to the instance. I’m installing both on the same line, using the following command.

Install-WindowsFeature Web-Server, Web-Mgmt-Service

 

It shouldn’t take too long. When it’s done you’ll get your output showing it’s complete.

 

Now that everything is installed, there is actually a registry key that needs modified. RegEdit is able to launch from Server Core from the command line, and you’ll need to set the following key to “1” rather than the default setting of “0”.

HKLM\SOFTWARE\Microsoft\WebManagement\Server\EnableRemoteManagement

 

Right, now we’ve got the settings in place. Unfortunately things still don’t work. That’s because the IIS Remote Management Service is disabled by default. Let’s go ahead and fix that by setting the service startup type to “automatic”, starting the service, and querying it’s state to confirm. We will do that by using the following three commands.

Set-Service WMSVC -StartupType “Automatic”

Start-Service WMSVC

Get-Service WMSVC

 

The status is now running, so we should be good to go. Let’s give it a shot by going into the GUI management server, launching the IIS console, and connecting to the server core box.

 

It will prompt you for the server name, and a user/password combo. After which, everything should be all set!

 

 

So there you have it, we’ve configured all the required settings to remotely manage IIS on server core!

I hope this makes your day at least a little bit easier.

Thanks,

PowerShell Script to Check Symantec Endpoint Protection Definition Updates

Posted on Updated on

Reading Time: 2 minutes

Symantec Endpoint Protection has quite a hold on the Anti-Virus market share. Many have environments where it’s used, and may not be the administrators or even able to view data from the Symantec Endpoint Protection Manager. In light of that, I’ve written a PowerShell script to check the last update time for SEP definitions that can either be run manually or set as a scheduled task.

# Check if Symantec Endpoint Protection is installed. If not, exit.

#Check last write date of AV definitions and compare to a variable set for time – 7 days. 

# Write to the event log whether definitions are current or not

#Send email if definitions are out of date

*Things to Note*

  • As it stands, in each of the “if ($writetime” blocks there is a “write-host”. If you plan on running this as a scheduled task you’ll want to remove or comment out those lines.
  • I will also be writing this as a SCOM management pack, and an SCCM Compliance Item.

 



###################################################################
## Check Symantec Endpoint Protection Antivirus Definition Dates ##
## v1.1 ##
## Matt Hansen // 01-06-2017 ##
###################################################################

#Set Variables
$hostname = hostname
$7daysago = (get-date).AddDays(-7)
$key = 'HKLM:SOFTWARE\Wow6432Node\Symantec\Symantec Endpoint Protection\CurrentVersion\SharedDefs'

#Test for registry key path and execute if neccessary
if (test-path -path $key)
{

$path = (Get-ItemProperty -Path $key -Name DEFWATCH_10).DEFWATCH_10
$writetime = [datetime](Get-ItemProperty -Path $path -Name LastWriteTime).lastwritetime
#Write-Host A min ago was $7daysago. DEFs was last written at $writetime

if ($writetime -lt $7daysago)
{Write-host "You have old defs"
Write-EventLog -LogName "Application" -Source "Symantec Antivirus" -EventId "7076" -EntryType "Warning" -Message "Symantec Definitions are older than 7 days. Last update time is was $writetime"
$notify = "yes"
}

if ($writetime -gt $7daysago)
{Write-host "You have current defs"
Write-EventLog -LogName "Application" -Source "Symantec Antivirus" -EventId "7077" -EntryType "Information" -Message "Symantec Definitions are current within 7 days. Last update time is was $writetime"
$notify = "no"

}

#Email Notify
if ($notify -eq "yes")
{
$param = @{
SmtpServer = "smtpserver@company.local"
Port = 25
UseSsl = $false
#Credential = "you@gmail.com"
From = "SymantecDefChecks@mcompany.local"
To = "administrator@company.local"
Subject = "Symantec Defintions Out-of-Date on $hostname"
Body = "Symantec Definitions are older than 7 days. Last update time is was $writetime on $hostname"
}
Send-MailMessage @param
#write-host "Email Sent"
}

}
Else {Write-host "Not installed"}

I hope this makes your day at least a little bit easier.

Thanks,

How to move SCVMM VMs into a Cloud

Posted on

Reading Time: 2 minutes

If you’ve ever added hosts to an SCVMM instance you’ll know that there’s seeminly no easy way to move the newly imported VMs from those hosts into SCVMM clouds. I’ve found the best way to do this is by using the SCVMM command-line interface, which unfortunately has a few quirks.

Set-SCVirtualMachine is the command you’ll need to use, with the flag “-Cloud” like in the example below.

Set-SCVirtualMachine -VM “NewVM1” -Cloud “Cloud1”

Unfortunately, every time I’ve tried this I’ve gotten an error saying it can’t convert the value type correctly like as shown below.

setscvm-failure

 

For whatever reason, I’ve found that the work around here is to set both the VM and the Cloud as variables and run the command again.

$VM = Get-SCVirtualMachine “NewVM1”

$Cloud = Get-SCCloud “Cloud1” 

Set-SCVirtualMachine -VM $VM -Cloud $Cloud

setscvm-success

 

Then we have success!

 

sccloud-success

 

I’ve yet to figure out why this is, but at least it works.

I hope this makes your day at least a little bit easier.

Thanks,

SCVMM Error 2912 “The configuration registry database is corrupt (0x800703F1)”

Posted on

Reading Time: < 1 minute

I recently spun up a new SCVMM environment, created my first VM, and attempted to create a template only to be faced with a job error.

Error (2912)
An internal error has occurred trying to contact the Host01 server: : .

WinRM: URL: [http://Host01.lab.local:5985], Verb: [INVOKE], Method: [LoadSubkey], Resource: [http://schemas.microsoft.com/wbem/wsman/1/wmi/root/scvmm/P2VSourceFixup?RegFileName=C:\Users\SVC_VMM\AppData\Local\Temp\tmp6AB5.tmp]

The configuration registry database is corrupt (0x800703F1)

Recommended Action
Check that WS-Management service is installed and running on server host01.lab.local. For more information use the command “winrm helpmsg hresult”. If host01.lab.local is a host/library/update server or a PXE server role then ensure that VMM agent is installed and running. Refer to http://support.microsoft.com/kb/2742275 for more details.

 

I’ve seen this issue before and typically it’s because I go on auto-pilot and sysprep the VM by hand. That will cause an issue, go ahead and start the VM and login, shutdown and let VMM do the sysprep.

Unfortunately this time that wasn’t the problem, though it was similar. When I shut the VM down I accidentally hit “Turn Off” and it hard powered the VM down. A simple boot, login, and retry fixed the problems here.

 

I hope this makes your day at least a little bit easier.

Thanks,

Disable Windows Firewall With PowerShell

Posted on

Reading Time: < 1 minute

Welcome all, to the age of the gui-less windows server. As more and more people spin up labs with command-line only boxes, this command can be helpful.

Remember to only turn off your firewall in lab environments where you know you’re not exposing  yourself to additional risk.

Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

 

To do this using netsh in cmd, you can use the following command.

 

netsh advfirewall set allprofiles state off

 

I hope this makes your day at least a little bit easier.

Thanks,

Task Manager Freezes on Windows 8/Server 2012

Posted on Updated on

Reading Time: 2 minutes

I’m the kind of guy that ALWAYS has task manager open. I’m serious, ask anyone I work with — I sometimes even have a whole screen for Task Manager and Resource Monitor (Maybe that’s why I like SCOM so much?). Though, I’ve noticed a couple of times on Windows 8, Windows 8.1, Server 2012, Server 2012 R2 that when I open task manager the stats just freeze. The system is fine, everything is normal but the stats just freeze — like this.

frozen.PNG

 

They never do anything else, and just stay at that initial opening mark. So frustrating! I’ve SFC’d, I’ve rebuilt my performance library, I’ve copied new bits for taskmgr.exe, everything! It turns out for some reason sometimes the view speed gets set to pause. I never would have though of that, but somehow it just happens (though, I’ve never seen it happen in any OS earlier than Windows 8/Server 2012).

 

Here’s how you fix it. Go into View –> Update speed and notice it’s set to pause. So strange.

paused.PNG

 

Go ahead and set it to normal and you’re back in business!

normal.PNG

 

I hope I’ve made your day, at least a little bit easier.

 

Thanks,

Server 2012 R2 “does not have a network adapter available to create a virtual switch” when configuring VDI

Posted on

Reading Time: 2 minutes

I recently ran into this issue when doing an all-in-one VDI install, on top of a server that had been used for other things in the past. The “quick start” VDI option is supposed to essentially do everything for you, but I ran into this issue.

“The Server does not have a network adapter available to create a virtual switch”

fail1

 

Taking a quick look here, I do have a vSwitch. Why is it complaining?

vSwitches

 

 

It turns out that the installer isn’t actually complaining about the fact that there is no vSwitch, it’s complaining that there IS a vSwitch. It needs it to be a “blank slate” so it can manage it and do it’s thing. I’m not a fan of this, because I intend to manage my VDI environment using SCVMM, and the VDI component itself won’t have a whole lot to say about it. Nevertheless, this is how you get past this. Delete any vSwitches.

 

no-vSwitch

 

 

All gone, now try the installer again.

 

done

 

 

There we go, now we’re off onto the next step without any errors. Have fun!

 

I hope I’ve made your day, at least a little bit easier.

Thanks!

SCCM Client Logs for Software Update Troubleshooting

Posted on

Reading Time: < 1 minute

We all know SCCM can be your best friend, and your worst nightmare. Today I had to compile a list of client logs to check for a friend of mine, and thought I’d share. These should get you 95% of the way on your troubleshooting (from the client side anyways). Remember to always use CMTrace as your SCCM log viewer, it just makes your life easier.

All of these listed directly below, should be located in C:\Windows\CCM\logs on your client.

  • UpdatesDeployment.log 
    • Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.
  • UpdatesHandler.log
    • Provides information about software update compliance scanning and about the download and installation of software updates on the client.
  • ScanAgent.log
    • Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.
  • WUAHandler.log
    • Provides information about when the Windows Update Agent on the client searches for software updates.
  • UpdatesStore.log
    • Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.

You can also reference C:\Windows\WindowsUpdate.log which is a windows native log and not to SCCM, but is updated with actions taken by SCCM in regards to updates.

 

 

I hope this has made your day, at least a little bit easier!

Thanks!