In the former blog post :https://robertsmit.wordpress.com/2018/11/29/step-by-step-windows-server-2019-file-server-clustering-with-powershell-or-gui-cluster-ha-azure-windowsadmincenter-windowsserver2019/
I created a File share on a Cluster to make the share HA. This is more the traditional way to make the share HA. But what if you have multiple locations and you want to use this share in Azure. Big internal lines between the Datacenter and copy the files to Azure (DFS) method. but that’s old. Better use the Azure File Sync option the files are synced to all the Server and available in Azure. Better and faster.
#bettertogether
With Azure File Sync , shares can be replicated on-premises or in Azure and accessed through SMB or NFS shares on Windows Server. Azure File Sync is useful for scenarios in which data needs to be accessed and modified far away from an Azure datacenter, such as in a branch office scenario. Data may be replicated between multiple Windows Server endpoints, such as between multiple branch offices. Azure File Sync transforms Windows Server into a quick cache of your Azure file share. You can use any protocol that’s available on Windows Server to access your data locally, including SMB, NFS, and FTPS. You can have as many caches as you need across the world.
To get started with the Azure File Sync we need a Storage account in Azure.
We create a storage account in Azure.
Remember this works only on Windows Servers ! System Requirements:
-
A server running Windows Server 2012 R2, Windows Server 2016 or Windows Server 2019:
Version
Supported SKUs
Supported deployment options
Windows Server 2019
Datacenter and Standard
Full (server with a UI)
Windows Server 2016
Datacenter and Standard
Full (server with a UI)
Windows Server 2012 R2
Datacenter and Standard
Full (server with a UI)
Now that the storage account is created we are starting with the Azure File Sync creation in Azure.
Name the Storage Sync Service , and create a resource group.
The next step is register the Onpremise server to Azure with the Azure File Sync Agent
Azure File Sync Agent download https://go.microsoft.com/fwlink/?linkid=858257
The installation is in two steps.
- Installing the agent
- Configuring the Agent
After the download install the Agent on the File server, As I use a Cluster install the Agent on every node of the Cluster.
Now that the agent is installed the Second wizard pops up for the configuration and if needed a update.
So far so good. As the Agent is connecting to Azure there are some additional components needed.
As this Cluster was a fresh installation and I did not used the PowerShell command for Azure here I need to install the AzureRM modules (or AZ module)
https://go.microsoft.com/fwlink/?linkid=856959
Installing and updating the modules.
Install-Module -Name AzureRM –AllowClobber
With this command you can see the current Powershell version
Get-Module -Name AzureRM -List | select Name,Version
Now that the PowerShell commands are installed we can refresh the page and the installation continues
If you are using a CSP subscription in Azure then you need to set this check box. and use your tenant ID
In all other subscriptions keep this default
Pick the right Resource group the one with the created Storage Sync services in it. else the field will be empty.
Select a resource group that contains a Storage Sync Service, or use the Azure portal to create one in this resource group.
When this process is done we can configure the rest in the Azure portal.
As you can see the Cluster CNO object is named here
In the pane that opens, enter the following information to create a sync group with a cloud endpoint:
- Sync group name: The name of the sync group to be created. This name must be unique within the Storage Sync Service, but can be any name that is logical for you.
- Subscription: The subscription where you deployed the Storage Sync Service.
- Storage account: If you select Select storage account, another pane appears in which you can select the storage account that has the Azure file share that you want to sync with.
- Azure file share: The name of the Azure file share with which you want to sync.
Next is creating the Sync group.
Pick a name for the Sync group name. and the proper Storage account that we created earlier. In this storage account we did not create a File share this is needed to hold the Files. so the azure file share check box is not showing you anything.
Go the the storage account and create a File share
With this created the creation of the Sync group can be completed.
Next step is creating some endpoints. this means bind the local share to the services and sync this to the Azure storage account share.
Adding the endpoint and pick the registered server and the file share that will be synced.
If you want to enable cloud Tiering and fill in the values. In this demo I don’t use this.
Note:
Only NTFS volumes are supported. ReFS, FAT, FAT32, and other file systems are not supported.
Failover Clustering
Windows Server Failover Clustering is supported by Azure File Sync for the "File Server for general use" deployment option. Failover Clustering is not supported on "Scale-Out File Server for application data" (SOFS) or on Clustered Shared Volumes (CSVs).
The Azure File Sync agent must be installed on every node in a Failover Cluster for sync to work correctly.
In my demo the Share is not listed, I already know why, As I used ReFS for the cluster disk.
This can be painful as you need to format that disk and move all the data to a temp location.
After changing the disk format and a refresh you can see that the deployment is pending and working.
After this you have a full Hybrid file share Fully redundant on premise and a off load to Azure.
As last the best option to get the data into this HA file share is using the Windows Admin Center
In Windows Admin Center there is a great options Storage Migration Services
Opening Windows admin Center and select the source this will be scanned and when done the files can be migrated. (the scanning can take some time)
When the scanning is done the files and shares are listed. more info can be found here https://youtu.be/WCWxAp27ERk
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
Installing the Cluster is easy now days. But just this I post a little blog on how to do this, In my blog stats it shows that the 2012 post is still very active , so time for an update to Windows Server 2019. in the creation there isn’t much changed, it gets only easier. but If you still not in PowerShell you got more clicks to do an less Coffee. And Windows Admin Center is also a great addition to manage a cluster. This blog post is also usable in Azure Only you need to add Storagespacesdirect and a CSV file share.
Just install a bare metal (VM) windows Server 2019 and do a domain join and the fun can start.
Installing the Cluster Feature in powershell
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
#Create cluster validation report
Test-Cluster -Node MVP19-01,MVP19-02
#Create new Cluster
New-Cluster -Name MVP1911-27 -Node MVP19-01,MVP19-02 -NoStorage -StaticAddress "10.255.255.45"
#place witness file on USB device from my router
Set-ClusterQuorum -FileShareWitness \\SERVER\SHARE -Credential $(Get-Credential)
Now that the basic cluster is ready we start with the HA share
File share witness enhancements We enabled the use of a file share witness in the following scenarios:
- Absent or extremely poor Internet access because of a remote location, preventing the use of a cloud witness.
- Lack of shared drives for a disk witness. This could be a Storage Spaces Direct hyperconverged configuration, a SQL Server Always On Availability Groups (AG), or an * Exchange Database Availability Group (DAG), none of which use shared disks.
- Lack of a domain controller connection due to the cluster being behind a DMZ.
-
A workgroup or cross-domain cluster for which there is no Active Directory cluster name object (CNO). Find out more about these enhancements in the following post in Server & Management Blogs: Failover Cluster File Share Witness and DFS.
We now also explicitly block the use of a DFS Namespaces share as a location. Adding a file share witness to a DFS share can cause stability issues for your cluster, and this configuration has never been supported. We added logic to detect if a share uses DFS Namespaces, and if DFS Namespaces is detected, Failover Cluster Manager blocks creation of the witness and displays an error message about not being supported.
that’s it the cluster is created, we can start with the File server
Next is installation of the file server role
A restart is needed! After the restart we can build the cluster with the HA file share
$servers = ("MVP19-01", "MVP19-02")
foreach ($server in $servers) {Install-WindowsFeature -Name file-services -ComputerName $server}
Now that the File Server Role is added we can add the Disk. Or use a disk that you already added before.
First we need to add a disk this can be done in the Failover Cluster manager or with PowerShell
Get-ClusterAvailableDisk | Add-ClusterDisk
The Roles are there and the Disk is added
Next step is adding the File server Role to the Cluster and add the HA File Share.
In this case I have a fail over disk and I use the File Server for general use.
So when adding the Disk it is not showing the disk. This is The disk is added to the cluster but the disk isn’t formatted!
Keep in mind that formating the cluster disk while it is online is not possible. You need to set the disk in maintenance mode else the format will fail.
So after the disk format we will see the Disk appear and can be added to the File server
After this the File server is up and running. As you can see the setup is screen intense, building this with PowerShell is a lot faster.
Powershell
add-ClusterFileServerRole -Storage "Cluster Disk 1" -Name MyFiles
New-SmbShare -Name "Data" -Path "J:\Data" -EncryptData $True
Quick steps with powershell and even the share is created and encrypted
Next step is adding the file share.
go for the Quick setup
Pick the disk and select the folder with the data on the disk, if there is no data then create a folder that will hold the data later.
as you can see the UNC path from the File Server.
As you can see the settings can be adjusted for you needs and also set the right access, and keep in mind this needs to be don on the Cluster Level!
All Done
So creating a File Server and 2 file shares is Click intensive if you don’t use PowerShell.
But What about Windows Admin Center ? yes that would be an option also except here you can’t create a cluster role.
You can create a new role but no file server /share etc.
But when the share is created and running like now you can use Windows Admin Center for migration the data to the file share.
But more and more options are coming in Windows Admin Center below are some links that you can use to add your request to the UserVoice
https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/manage-failover-clusters
More Coming
Failover cluster management in Windows Admin Center is actively under development and new features will be added in the near future. You can view the status and vote for features in UserVoice:
Feature Request
Show more clustered disk info
Support additional cluster actions
Support converged clusters running Hyper-V and Scale-Out File Server on different clusters
View CSV block cache
See all or propose new feature
+++++++++++++++
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
Distributed denial of service (DDoS) attacks are some of the largest availability and security concerns facing customers that are moving their applications to the cloud. A DDoS attack attempts to exhaust an application’s resources, making the application unavailable to legitimate users. DDoS attacks can be targeted at any endpoint that is publicly reachable through the internet.
What is DDoS Protection? Protecting applications from DDoS attacks has been one of the top security concerns for Azure customers. Azure DDoS protection service is an Azure Networking offering aimed at protecting publicly accessible endpoints from DDoS attacks. The offering gives customers access to the same protection that is used to protect Microsoft’s online assets, such as Xbox Live and Office 365. Azure DDoS protection service provides constant network flow monitoring of the protected endpoints, and when detecting a DDoS attack, automatically applies traffic scrubbing to make sure only legitimate requests are forwarded to the application.
Azure DDoS protection, combined with application design best practices, provide defense against DDoS attacks. Azure DDoS protection provides the following service tiers:
- Basic: Automatically enabled as part of the Azure platform. Always-on traffic monitoring, and real-time mitigation of common network-level attacks, provide the same defenses utilized by Microsoft’s online services. The entire scale of Azure’s global network can be used to distribute and mitigate attack traffic across regions. Protection is provided for IPv4 and IPv6 Azure public IP addresses.
- Standard: Provides additional mitigation capabilities over the Basic service tier that are tuned specifically to Azure Virtual Network resources. DDoS Protection Standard is simple to enable, and requires no application changes. Protection policies are tuned through dedicated traffic monitoring and machine learning algorithms. Policies are applied to public IP addresses associated to resources deployed in virtual networks, such as Azure Load Balancer, Azure Application Gateway, and Azure Service Fabric instances, but this protection does not apply to App Service Environments. Real-time telemetry is available through Azure Monitor views during an attack, and for history. Rich attack mitigation analytics are available via diagnostic settings. Application layer protection can be added through the Azure Application Gateway Web Application Firewall or by installing a 3rd party firewall from Azure Marketplace. Protection is provided for IPv4 Azure public IP addresses.
So how to start with DDoS in Azure.
First go to the Virtual Networks.
Next selecting the Network and in the left pane there is a section DDoS Protection.
Selecting the DDoS Protection there is the Basic and the Standard Setting
Pricing Details
There the Basic is the default and comes with free pricing.
The Standard is a different option and Cost you some real money! and these are monthly costs. For a demo I turned it on and forget to turned it of and spend 10K in 4 months so keep a track on your Azure costs.
The DDoS Protection service will have a fixed monthly charge, as well as a charge for data processed. The fixed monthly charge includes protection for 100 resources. Protection for additional resources will be charged on a monthly per-resource basis.
Monthly price for DDoS Protection (includes protection for 100 resources): €2,483/month
Overage charges (more than 100 resources): €25 per resource per month
When Enabling the DDoS Standard we need to create a DDoS protection plan first, if you have already one you can add the ID.
Check the create DDoS protection Plan
Now that we created a plan witch is more a resource place holder, we can add this to the DDoS protection plan
Now that the DDoS and the plan is in place we can create an alert rule in case we have a DDoS attack.
In the Azure Monitor we can create the alert rule and we can see the logging.
To see telemetry for a DDoS attack, log into the Azure Portal and navigate to the “Monitor” blade.
Within the monitor blade, click on “Metrics”, select the appropriate subscription, resource group, resource type of “Public IP” and the Public IP that was the target of the attack. After selecting the resource, a series of Available Metrics will appear on the left side. These metrics are selected and then will be graphed.
The metric names are relatively self-explanatory and the basic construct is that there are tag names on each metric as follows: • Dropped tag name (e.g. Inbound Packets Dropped DDoS): The number of packets dropped/scrubbed by the DDoS system
• Forwarded tag name (e.g: Inbound Packets Forwarded DDoS): The number of packets forwarded by the DDoS system to the destination VIP – traffic that was not filtered • No tag name (e.g: Inbound Packets DDoS): The total number of packets that came into the scrubbing system – representing the sum of the packets dropped and forwarded
The traffic shown in the Monitor dashboard.
To create a dashboard there are some options with counters. It all depends on your need.
now we create an alert rule.
Email Alerting To configure an email alert for a metric, click on the “Click to add an alert” text. An email alert can be created on any metric, but the most obvious metric to create an alert on is “Under DDoS attack or not”. This is a boolean value 1 or 0. “1” means you are under attack. “0” means you are not under attack. To be emailed when under attack, set the Metric for “Under DDoS attack or not” and “Condition” to “Greater than” zero (0) over the last 5 minutes. Similar alerts can be set up for other metrics. An example screenshot is provided below.
To divine the Severity I keep this as this is also be used in SCOM
Azure Monitor Alert Severity Levels
Sev 0 = Critical
Sev 1 = Error
Sev 2 = Warning
Sev 3 = Informational
Sev 4 = Verbose
Last part in selecting the email for this alert.
With this setup you got a good protection against DDoS attacks. below is the workflow how DDoS protection works.
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
In the old days all File servers where on one place, and if you want to replicate data you needed a extra tool to do this. Now days its already build in into Windows server. Storage replica can be used in several ways, replicate data from one Cluster to another or to Azure. but in this case I do a server to server replication as not everyone has a cluster.
For moving data to the Cloud there are currently several other applications like Azure file sync or Azure Migrate https://docs.microsoft.com/en-us/azure/migrate/migrate-overview Blog about Azure File Sync https://robertsmit.wordpress.com/2017/09/28/step-by-step-azure-file-sync-on-premises-file-servers-to-azure-files-storage-sync-service-afs-cloud-msignite/
Storage Replica is Windows Server technology that enables replication of volumes between servers or clusters for disaster recovery. It also enables you to create stretch failover clusters that span two sites, with all nodes staying in sync.
Storage Replica supports synchronous and asynchronous replication:
- Synchronous replication mirrors data within a low-latency network site with crash-consistent volumes to ensure zero data loss at the file-system level during a failure.
- Asynchronous replication mirrors data across sites beyond metropolitan ranges over network links with higher latencies, but without a guarantee that both sites have identical copies of the data at the time of a failure.
Storage Replica allows more efficient use of multiple datacenters. By stretching clusters or replicating clusters, workloads can be run in multiple datacenters for quicker data access by local proximity users and applications, as well as better load distribution and use of compute resources. If a disaster takes one datacenter offline, you can move its typical workloads to the other site temporarily.
Storage Replica may allow you to decommission existing file replication systems such as DFS Replication that were pressed into duty as low-end disaster recovery solutions. While DFS Replication works well over extremely low bandwidth networks, its latency is very high – often measured in hours or days. This is caused by its requirement for files to close and its artificial throttles meant to prevent network congestion. With those design characteristics, the newest and hottest files in a DFS Replication replica are the least likely to replicate. Storage Replica operates below the file level and has none of these restrictions.
Storage Replica also supports asynchronous replication for longer ranges and higher latency networks. Because it is not checkpoint-based, and instead continuously replicates, the delta of changes will tend to be far lower than snapshot-based products. Furthermore, Storage Replica operates at the partition layer and therefore replicates all VSS snapshots created by Windows Server or backup software; this allows use of application-consistent data snapshots for point in time recovery, especially unstructured user data replicated asynchronously.
The Setup I used two servers both domain joined, And there are different ways to configure the Storage Replica, the easy way and the 10 second way.
First we are installing the Storage replica feature and the File server Role. The Storage replica feature needs a reboot.
Or use Powershell
install-WindowsFeature "Storage-Replica" –IncludeAllSubFeature
If you don’t know the module name you can find it easily
A reboot is needed.
Doing this server by server is not handy, So placing this together saves us some time.
$Servers = “Building-5”,”Building-9”
$Servers | ForEach { Install-WindowsFeature -ComputerName $_ -Name Storage-Replica,FS-FileServer -IncludeManagementTools -restart }
The –restart does an automatic restart if this is needed.
Storage Replica prerequisites
- Active Directory Domain Services forest.
- Storage Spaces with SAS JBODs, Storage Spaces Direct, fibre channel SAN, shared VHDX, iSCSI Target, or local SAS/SCSI/SATA storage. SSD or faster recommended for replication log drives. Microsoft recommends that the log storage be faster than the data storage. Log volumes must never be used for other workloads.
- At least one Ethernet/TCP connection on each server for synchronous replication, but preferably RDMA.
- At least 2GB of RAM and two cores per server. (with less memory the replication won’t start)
- A network between servers with enough bandwidth to contain your IO write workload and an average of 5ms round trip latency or lower, for synchronous replication. Asynchronous replication does not have a latency recommendation.
As there is no Gui on the replica part we need to configure this by PowerShell or with the new Windows Admin Center
Both our servers had Two extra disks. One log and Data Disk.
- You must create two volumes on each enclosure: one for data and one for logs.
- Log and data disks must be initialized as GPT, not MBR.
- The two data volumes must be of identical size.
- The two log volumes should be of identical size.
- All replicated data disks must have the same sector sizes.
- All log disks must have the same sector sizes.
- The log volumes should use flash-based storage, such as SSD. Microsoft recommends that the log storage be faster than the data storage. Log volumes must never be used for other workloads.
- The data disks can use HDD, SSD, or a tiered combination and can use either mirrored or parity spaces or RAID 1 or 10, or RAID 5 or RAID 50.
- The log volume must be at least 9GB by default and may be larger or smaller based on log requirements.
- The File Server role is only necessary for Test-SRTopology to operate, as it opens the necessary firewall ports for testing.
As you can see there are some needs for the Replication As I show you below with the performance test why you need this.
First we are configuring the Disks on both servers. with some PowerShell commands but this can also be done with Disk manager.
Get-Disk | Where FriendlyName -eq ‘Msft Virtual Disk’
Get-Disk | Where FriendlyName -eq ‘Msft Virtual Disk’|Initialize-Disk -PartitionStyle GPT –PassThru
1..2 | % { Get-Disk $_ }| Where FriendlyName -eq ‘Msft Virtual Disk’|New-Partition -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem ReFS -NewFileSystemLabel "SR01-disk" -Confirm:$false
I formatted the disk with ReFS and not with NTFS.
Now that the disks are in place we can start but before we start building the replica I want to make sure the connection and the network is fast and the server can deliver the performance we need.
Therefor I download a test tool Diskspd. https://aka.ms/diskspd
Important is that the network speed between the server is good as this is the life line for the storage replica. We can test the replication before the build things for real.
With this test tool we bring up a small load to test the server.
Using the Diskspd with the line below.
Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 –i100 –j2 E:\test
Storage replica has a great test tool report. So with this we configure the test. Using Powershell
MD c:\temp
Test-SRTopology -SourceComputerName "Building-5" -SourceVolumeName "e:" -SourceLogVolumeName "f:" -DestinationComputerName "Building-9" -DestinationVolumeName "e:" -DestinationLogVolumeName "f:" -DurationInMinutes 30 -ResultPath c:\Temp
#set output file
$outputfile="$Env:TEMP"
Test-SRTopology -SourceComputerName "Building-5" -SourceVolumeName "e:" -SourceLogVolumeName "f:" -DestinationComputerName "Building-9" -DestinationVolumeName "e:" -DestinationLogVolumeName "f:" -IntervalInSeconds 5 -DurationInMinutes 30 -ResultPath $outputfile
#open output file
If (Test-Path $outputFile) { Invoke-Item $outputFile\TestSrTopologyReport.html } Else { Write-Host "FAILED: Output file not found: $url" -fore red }
Write-Host "Done" -ForegroundColor Cyan
while running the Test-SRTopology with the -DurationInMinutes 30 option we also run Diskspd.
Diskspd.exe -c1g -d600 -W5 -C5 -b8k -t2 -o2 -r -w5 –i100 –j2 E:\test
It is a 1 Gb file placed on our E drive that is our Data disk for replication.
As you can see I have just one network adapter and no RDMA and in this config I hit the limit of the CPU and the network card max 4.4 Gbps not bad for a test config. (if you use a better machine in Azure Pick a Azure H-series those have RDMA
One CPU with 99% usage.
When the test is done the is a log file created in -ResultPath c:\Temp
Open the log file and detailed information is there about the test. this is why I choose 30 min duration.
Nice graph about the Data throughput, in this case not bad.
the Latency is always a issue this could change you from sync to async or more network adapters or better disks. But for now it is good.
Log Volume Free Disk Space Test: The log volume F: in Building-5 has enough free space to hold the recommended log volume size of 8GB
Log Volume Free Disk Space Test: The log volume F: in Building-9 has enough free space to hold the recommended log volume size of 8GB
Storage replica has not that much PowerShell commands
#list all the commands
get-command *sr*
Setting up the actual replica is done with a long PowerShell command
The default log size is 8GB. Depending on the results of the Test-SRTopology cmdlet, you may decide to use -LogSizeInBytes with a higher or lower value.
New-SRPartnership -SourceComputerName "Building-5" –SourceRGName rg01 -SourceVolumeName "e:" -SourceLogVolumeName "f:" -DestinationComputerName "Building-9" –DestinationRGName rg02 -DestinationVolumeName "e:" -DestinationLogVolumeName "f:"
The default log size is 8GB. Depending on the results of the Test-SRTopology cmdlet, you may decide to use -LogSizeInBytes with a higher or lower value.
New-SRPartnership -SourceComputerName "Building-5" –SourceRGName rg01 -SourceVolumeName "e:" -SourceLogVolumeName "f:" -DestinationComputerName "Building-9" –DestinationRGName rg02 -DestinationVolumeName "e:" -DestinationLogVolumeName "f:" -LogSizeInBytes 1gb
here you can see the disk setup between both servers, the active side you can access the data disk, on the passive side the disk is not accessible.
Don’t place files on the Log disk.
To get replication source and destination state, use Get-SRGroup and Get-SRPartnership
Get-SRGroup
Get-SRGroup |fl *
Get-SRPartnership
(Get-SRGroup).replicas
This is just after the creation so no data yet for the last time in sync.
New-SRPartnership -SourceComputerName "Building-5" –SourceRGName rg01 -SourceVolumeName "e:" -SourceLogVolumeName "f:" -DestinationComputerName "Building-9" –DestinationRGName rg02 -DestinationVolumeName "e:" -DestinationLogVolumeName "f:"
For troubleshooting there are some events that you can check, go to the event viewer and check for the Storage replica events.
Or check the events with PowerShell
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
On the destination server, we can do the same or look for the events in the eventlog.
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica | Where-Object {$_.ID -eq "1215"} | fl
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
There are also a lot of performance counters that can be viewed with PowerShell
Get-Counter -Counter "\Storage Replica Statistics(*)\Total Bytes Received"
Get-Counter -Counter "\Storage Replica Statistics(*)\Total Bytes Sent"
Get-Counter -Counter "\Storage Replica Statistics(*)\Avg. Network Send Latency"
Get-Counter -Counter "\Storage Replica Statistics(*)\Replication State"
Get-Counter -Counter "\Storage Replica Statistics(*)\Last Recovery Elapsed Time"
Get-Counter -Counter "\Storage Replica Partition I/O Statistics(*)\Number of times flush paused"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Flushed Recovery Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Recovery Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Flushed Replication Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Replication Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Messages Received"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Messages Sent"
Get-Counter -Counter "\Storage Replica Partition I/O Statistics(*)\Avg. App Write Latency"
Get-Counter -Counter "\Storage Replica Partition I/O Statistics(*)\Avg. App Read Latency"
Get-Counter -Counter "\Storage Replica Statistics(*)\Target RPO"
Get-Counter -Counter "\Storage Replica Statistics(*)\Current RPO"
Get-Counter -Counter "\Storage Replica Statistics(*)\Avg. Log Queue Length"
Get-Counter -Counter "\Storage Replica Statistics(*)\Current Log Queue Length"
Get-Counter -Counter "\Storage Replica Statistics(*)\Total Bytes Received"
Get-Counter -Counter "\Storage Replica Statistics(*)\Total Bytes Sent"
Get-Counter -Counter "\Storage Replica Statistics(*)\Avg. Network Send Latency"
Get-Counter -Counter "\Storage Replica Statistics(*)\Replication State"
Get-Counter -Counter "\Storage Replica Statistics(*)\Avg. Message Round Trip Latency"
Get-Counter -Counter "\Storage Replica Statistics(*)\Last Recovery Elapsed Time"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Flushed Recovery Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Recovery Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Flushed Replication Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Replication Transactions"
Get-Counter -Counter "\Storage Replica Statistics(*)\Max Log Sequence Number"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Messages Received"
Get-Counter -Counter "\Storage Replica Statistics(*)\Number of Messages Sent"
these counters look like this
To remove the Replication we run the following command :
Get-SRPartnership Get-SRPartnership | Remove-SRPartnership Get-SRGroup | Remove-SRGroup
Or change the direction of the replication just run the PowerShell command
#move the replication direction from one site, use the
Set-SRPartnership -NewSourceComputerName "Building-9" -SourceRGName rg02 -DestinationComputerName "Building-5" -DestinationRGName rg01
Why not use Windows Admin Center ?
But all this PowerShell my fear you on using this. Good news than when using Windows Admin Center
Windows Admin Center is a locally deployed, browser-based app for managing servers, clusters, hyper-converged infrastructure, and Windows 10 PCs. It comes at no additional cost beyond Windows and is ready to use in production.
Get it here
When opening the Source Storage Replica server you will see a quick over view of you configuration
Easy switch replication direction.
Notifications on the preformed actions
With an overview of the current configuration.
But the best part of Windows Admin Center is creating a new Replica. I removed the old replica and create a new one with the WAC.
Fill in the source and destination and your done.
With the Admin center you got a GUI wrapper for creating the Storage replica, No PowerShell needed
There are more options in Windows Admin Center that could be useful to you just try it.
And if you want to use file replication to Azure take a look at the Azure File Sync https://docs.microsoft.com/en-us/azure/storage/files/storage-files-introduction
https://robertsmit.wordpress.com/2017/09/28/step-by-step-azure-file-sync-on-premises-file-servers-to-azure-files-storage-sync-service-afs-cloud-msignite/
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
If you want to upgrade your domain controller and make this ready for server 2019. In this case I have only one Domain controller running server 2016.
When you do a Upgrade of your current Domain Controller you may get this message during the Setup of Windows server 2019
Go to the Source files of Windows server 2019 and look for ADPrep
In the command line adprep.exe /forestprep /forest <domainname>
If you press any other key than the C it will quit the upgrade.
Press C
You can see a upgrade from schema 87 to 88
next step is a domain prep
ADPrep /domainprep /domain <domainname>
No reboot is needed, go back to the Setup press refresh and the setup will continue.
Depending on the Computer Speed you will see this
If the installation fails keep an eye on the error code. In this case I had a simulation of this and I skipped some updates.
Checked the code and see the solution.
https://support.microsoft.com/en-us/help/10587/windows-10-get-help-with-upgrade-installation-errors
An error that begins with 0xC1900101 is usually a driver error. If you see any of these error codes, try the following steps first to fix the problem. If these steps don’t work, see Resolve Windows 10 upgrade errors for more detailed technical info.
- 0xC1900101 – 0x20004
- 0xC1900101 – 0x2000c
- 0xC1900101 – 0x20017
- 0xC1900101 – 0x30018
- 0xC1900101 – 0x3000D
- 0xC1900101 – 0x4000D
- 0xC1900101 – 0x40017
- Make sure that your device has enough space. Your device requires at least 16 GB of free space to upgrade a 32-bit OS, or 20 GB for a 64-bit OS. For more info, see Free up drive space in Windows 10.
- Run Windows Update a few times. Download and install any available updates in Windows Update, including software updates, hardware updates, and some third-party drivers. Use the troubleshooter for Windows 10 to fix Windows Update errors.
- Check third-party drivers and download any updates. You can find third-party drivers and installation instructions for any hardware you’ve added to your device on the manufacturer’s website.
- Unplug extra hardware. Remove all external storage devices and drives, docks, and other hardware you might have plugged into your device that isn’t needed for basic functionality.
- Check Device Manager for errors. Select the Start button, then in the search box on the taskbar, type device manager. Choose Device Manager from the results. In the window that pops up, look for any device with a yellow exclamation mark beside it (you may have to select each category to switch to the list of devices). Press and hold (or right-click) the device name and select either Update Driver Software or Uninstall to correct the errors.
- Remove third-party security software. Make sure you know how to reinstall your programs and that any necessary product keys are on hand. Windows Defender will help protect your device in the meantime.
- Repair hard-drive errors. Select the Start button, then in the search box on the taskbar, type command prompt. Choose Command Prompt from the list of results. In the window that pops up, type chkdsk/f C: and press the Enter key. Repairs automatically start on your hard drive, and you’ll be asked to restart your device.
I did do Option 2 and see the updates and installed it and retried the upgrade again and it worked without any issue.
After the update I did a restart for finishing the updates and another restart to make sure everything was fine then I restarted the upgrade successfully,
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
Ignite is almost there. The benefit of being an MVP is that whole week We already had pre-ignite sessions and warmed up for Ignite. these are exiting times a lot of new content will be there and when Microsoft is showing the products we can blog about this with out breaking our NDA.
Already some teasers Windows Admin Center would be named a lot. As this is the webbased tool to manage your servers. In Azure or on prem.
Storage is also a big Thing. and migration to Azure and or from of moving your old servers to Azure. this is also a big topic.
As moving to the cloud is nice and easy ( well not always) the client is there also Intune – Autopilot – Rdmi – The modern workplace
As last year Microsoft announced the new RDmi and at Inspire there where also some sessions about RDmi .
https://robertsmit.wordpress.com/2018/01/17/part2-ultimate-step-to-remote-desktop-services-html5-quickstart-deployment-rds-vdi-rdp-rdmi/
Above are some examples of the HTML5 Client that you already can use in the current RDS environment.
There will be a lot off content passing this week. Thanks for reading my blog and following me on twitter.
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
Windows Admin Center is a new, locally-deployed, browser-based management tool set that lets you manage your Windows Servers with no Azure or cloud dependency. Windows Admin Center gives you full control over all aspects of your server infrastructure and is particularly useful for managing servers on private networks that are not connected to the Internet.
With every new version there are new plugins or options in Windows Admin Center so you server management is getting easier and quicker. In this blog I will show you how to build a point to site VPN from a windows server 2019 with Windows Admin Center. You will need the Insiders preview For this.
The Azure Network Adapter extension in Windows Admin Center "automates the configuration for the Azure Virtual Network gateway as well as the on-premises VPN client," Microsoft’s announcement explained.
The setup of point-to-site VPN connections is enabled by using an Azure Network Adapter network extension in Windows Admin Center. In the Server manager under network there is the option to add the Azure VPN
Do the Azure Network adapter (ANA) + and If you are not registered to Azure already in the Windows Admin Center then you need to do this first.
Do the Register Windows Admin Center to azure.
Do Register, Remember you need to enable Popups I your browser is you are not allowing this.
Copy the Code and use this in the next login windows.
Paste the Code into the screen and you are sign in into Azure.
Windows Admin Center Azure Connection
The next steps are importand as most of us don read the text and just press next. ‘-)
We select a tenant what to use in the Azure portal. You can find the right ID in you Azure Active directory
By doing Properties you will see the Tenand ID
Do register.
As Most do next and complaining it doesn’t work see the text :
Require permissions then click Grand permissions on YES. So go to the Azure portal
You’ll need to visit the Azure portal to grant permissions to the application:
Go to the Azure AD app registration
Select ‘Settings’ > ‘Required permissions’, then click ‘Grant Permissions’ > ‘Yes’
If you for get this step the popup will fail and you can’t add the network.
Now we can really begin with the Azure VPN connection. #ANA
Fill in the details your subscription and location with the network.
If you don’t have a Azure network you need to create one first in the Azure portal, as a Point to site connection is connection to you azure network.
After a few moments you can see in the Azure Portal that the Gateway is created.
Note: The creation could take much longer (~25 minutes) if the Azure Virtual Network gateway needs to be created. In this case it is I did not have a gateway.
Once your Point-to-site VPN is “Connected” your server now has a connection to the Azure Virtual Network. The server will be able to communicate to any Azure resources in the Virtual Network.
In the Windows Admin Center you get a nice detailed overview of the connection. Once your Point-to-site VPN is “Connected” your server now has a connection to the Azure Virtual Network. The server will be able to communicate to any Azure resources in the Virtual Network.
On the Client you see also the extra networks. I created Two extra Point to Site connections. to two different subscriptions. just to see if this was working.
To test if the connection was working I connect to a Azure VM by the internal IP.
The internal network IP of the Azure VM.
As you can see the Created certificates to Azure are on the Windows server 2019.
See how easy this is!
Ready to give it a shot!? Try out Azure Network Adapter in the Windows Admin Center Version 1809!
Note: Windows Admin Center Version 1809 will be released in September.
Previously creating hybrid cloud connectivity required expertise in networking, certificate management, and even infrastructure setup and maintenance. Now with the Azure Network Adapter in Windows Admin Center (version 1809), hybrid connectivity can be configured with the click of a button! The Azure Network Adapter automates the configuration of the Azure Virtual Network gateway and VPN client installation for you!
Follow Me on Twitter @ClusterMVP
Follow My blog https://robertsmit.wordpress.com
Linkedin Profile Robert Smit MVP Linkedin profile
Google : Robert Smit MVP profile
Like this:
Like Loading...
