Task Scheduler - Repeat a task on a custom interval that is not selectable

In Windows Server 2008 and above you can set task to repeat on whatever you want. The corresponding drop down menu just present 5,10,15,30 minutes and 1 hour, but you can type in any number of hours or minutes you want to use.

There are some limitations you should know.

You can enter 2 hours, but not 2.5 hours. If you want to run a task every 2.5 hours, you have to enter the amount of minutes. Therefore, this would be 2.5 x 60 = 150 minutes.

Install Forest DC on Azure using Powershell

Folks,

I published a script on TechNet to install a DC on Azure using PowerShell.

Check it out:
https://gallery.technet.microsoft.com/Install-Forest-DC-on-Azure-33f2c9e8

Cheers,
Tim

Syncing NPS Settings between two servers

If you want to be redundant, you need a second server running NPS with all the settings you need to handle requests of your Radius Clients. Network devices typically allow you to specify multiple Radius Servers in their configuration using a shell or web interface. If you have two servers, you have to define a "Master Radius Server", so you can use this server to do all configuration changes and these changes have to be imported to a second server. You can sync your NPS configuration, manually via GUI or using a PowerShell script that running in a schedule task. Find attached a picture that show this process.

The following script could be used to sync your NPS configuration between two servers. This path C:\admin\NPS\Backup\ must be available on both servers. Just create them or add it to the sript.


# Get date
$date = get-date -Format yyyy_MM_dd
# Export NPS config
Export-NpsConfiguration -Path C:\admin\NPS\Backup\NPSConfig_$date.xml
Export-NpsConfiguration -Path C:\admin\NPS\Backup\NPSConfig.xml
# Destination Server
$NPSDestServer = "SecondRadius"
# Copy config to destination server
Copy-Item -path C:\admin\NPS\Backup\NPSConfig.xml -destination \\$NPSDestServer\C$\admin\NPS\NPSConfig.xml
# Export current config
Invoke-Command -ComputerName $NPSDestServer -ScriptBlock {Export-NPSConfiguration -Path C:\admin\NPS\BackupNPSConfig.xml}
# Import new config
Invoke-Command -ComputerName $NPSDestServer -ScriptBlock {Import-NPSConfiguration -Path C:\admin\NPS\NPSConfig.xml}


Just copy this script to your Master Radius, change $NPSDestServer = "SecondRadius" to match to your second NPS server name and create a schedule task that execute this script.

Verify you Windows Server Backups with notification

If you scheduled a Windows Server Backup, you can check for Errors and send an email if a Error happened.

To do this just schedule to run the following script after your backup job:

# Check EventLog for Error created by Windows Backup
If (Get-EventLog -LogName Application -EntryType Error -Source Microsoft-Windows-Backup -After (Get-Date).AddHours(-24))
    {
    #Set E-mail variables.
    $EmailFrom = "server@yourdomain.com"
    $EmailTo = "Tim.Buntrock@yourdomain.com"
    $Subject = "$env:COMPUTERNAME - Windows Backup failed"
    $Body = "$env:COMPUTERNAME - Windows Backup failed. Please logon to the server and verify your backup task!"
    $SMTPServer = "smtp01.yourdomain.com"
    #Send message
    Send-MailMessage -Subject $Subject -Body $Body -SmtpServer $SMTPServer -Priority High -To $EmailTo -From $EmailFrom
    }

Else
    {
    exit
    }

Thats it. :)

DFS-R stopped replication Event 4012

If the DFS-R service stopped replication and you can see Events with ID 4012 in the DFS Replication Log, you can do the following steps to resolve this issue.
First have a look into the event 4012:

In the log we can see that the server has been disonnected for 101 days. To resume the replication, we have to change MaxOfflineTimeInDays to a value above 101 or rebuild it.
I will show you how to set the value to resume the replication. Just do the following steps:
- Set MaxOfflineTimeInDays in cmd:
wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=102
- Restart DFS-R service in cmd:
net stop dfsr && net start dfsr

After that you can check the DFS Replication log and you will see that the replication resumed. It´s normal that it will detect conflicts (Event 4412).

Next Steps:
To prevent this issue, you can create a Powershell script that search for Event 2213 is logging the ROOT cause for Event 4412 that will be generated 60 days later. If an event was found it will send out an email. The Powershell script will be executed on a daily base in a schedule task, so you will be informed if this event happen on your server.