Azure Site Recovery support matrix for replicating to Azure

Azure Site Recovery support matrix for replicating to Azure

Reference Link : https://docs.microsoft.com/en-us/azure/site-recovery/site-recovery-support-matrix-to-azure#support-for-replicated-machine-os-versions

 

All About Azure Storage replication

All About Azure Storage replication

 

The data in your Microsoft Azure storage account is always replicated to ensure durability and high availability. Replication copies your data, either within the same data center, or to a second data center, depending on which replication option you choose. Replication protects your data and preserves your application up-time in the event of transient hardware failures. If your data is replicated to a second data center, that also protects your data against a catastrophic failure in the primary location.

Replication ensures that your storage account meets the Service-Level Agreement (SLA) for Storage even in the face of failures. See the SLA for information about Azure Storage guarantees for durability and availability.

When you create a storage account, you can select one of the following replication options:

·        Locally redundant storage (LRS)

·        Zone-redundant storage (ZRS)

·        Geo-redundant storage (GRS)

·        Read-access geo-redundant storage (RA-GRS)

Read-access geo-redundant storage (RA-GRS) is the default option when you create a new storage account.

The following table provides a quick overview of the differences between

Replication strategy LRS ZRS GRS RA-GRS           Data is replicated across multiple datacenters. No Yes Yes Yes Data can be read from the secondary location as well as from the primary location. No No No Yes Number of copies of data maintained on separate nodes. 3 3 6 6

Locally redundant storage

Locally redundant storage (LRS) replicates your data three times within a storage scale unit which is hosted in a datacenter in the region in which you created your storage account. A write request returns successfully only once it has been written to all three replicas. These three replicas each reside in separate fault domains and upgrade domains within one storage scale unit.

A storage scale unit is a collection of racks of storage nodes. A fault domain (FD) is a group of nodes that represent a physical unit of failure and can be considered as nodes belonging to the same physical rack. An upgrade domain (UD) is a group of nodes that are upgraded together during the process of a service upgrade (rollout). The three replicas are spread across UDs and FDs within one storage scale unit to ensure that data is available even if hardware failure impacts a single rack or when nodes are upgraded during a rollout.

LRS is the lowest cost option and offers least durability compared to other options. In the event of a datacenter level disaster (fire, flooding etc.) all three replicas might be lost or unrecoverable. To mitigate this risk Geo Redundant Storage (GRS) is recommended for most applications.

Locally redundant storage may still be desirable in certain scenarios:

·        Provides highest maximum bandwidth of Azure Storage replication options.

·        If your application stores data that can be easily reconstructed, you may opt for LRS.

·        Some applications are restricted to replicating data only within a country due to data governance requirements. A paired region could be in another country; please see Azure regions for information on region pairs.

 Zone-redundant storage

Zone-redundant storage (ZRS) replicates your data asynchronously across datacenters within one or two regions in addition to storing three replicas similar to LRS, thus providing higher durability than LRS. Data stored in ZRS is durable even if the primary datacenter is unavailable or unrecoverable. Customers who plan to use ZRS should be aware that:+

·        ZRS is only available for block blobs in general purpose storage accounts, and is supported only in storage service versions 2014-02-14 and later.

·        Since asynchronous replication involves a delay, in the event of a local disaster it is possible that changes that have not yet been replicated to the secondary will be lost if the data cannot be recovered from the primary.

·        The replica may not be available until Microsoft initiates failover to the secondary.

·        ZRS accounts cannot be converted later to LRS or GRS. Similarly, an existing LRS or GRS account cannot be converted to a ZRS account.

·        ZRS accounts do not have metrics or logging capability.

Geo-redundant storage

Geo-redundant storage (GRS) replicates your data to a secondary region that is hundreds of miles away from the primary region. If your storage account has GRS enabled, then your data is durable even in the case of a complete regional outage or a disaster in which the primary region is not recoverable.

For a storage account with GRS enabled, an update is first committed to the primary region, where it is replicated three times. Then the update is replicated asynchronously to the secondary region, where it is also replicated three times. With GRS, both the primary and secondary regions manage replicas across separate fault domains and upgrade domains within a storage scale unit as described with LRS.

Considerations:

·        Since asynchronous replication involves a delay, in the event of a regional disaster it is possible that changes that have not yet been replicated to the secondary region will be lost if the data cannot be recovered from the primary region.

·        The replica is not available unless Microsoft initiates failover to the secondary region. If Microsoft does initiate a failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, please see Disaster Recovery Guidance.

·        If an application wants to read from the secondary region, the user should enable RA-GRS.

When you create a storage account, you select the primary region for the account. The secondary region is determined based on the primary region, and cannot be changed. The following table shows the primary and secondary region pairings.

Primary	Secondary
North Central US	South Central US
South Central US	North Central US
East US	West US
West US	East US
US East 2	Central US
Central US	US East 2
North Europe	West Europe
West Europe	North Europe
South East Asia	East Asia
East Asia	South East Asia
East China	North China
North China	East China
Japan East	Japan West
Japan West	Japan East
Brazil South	South Central US
Australia East	Australia Southeast
Australia Southeast	Australia East
India South	India Central
India Central	India South
US Gov Iowa	US Gov Virginia
US Gov Virginia	US Gov Iowa
Canada Central	Canada East
Canada East	Canada Central
UK West	UK South
UK South	UK West
Germany Central	Germany Northeast
Germany Northeast	Germany Central
West US 2	West Central US
West Central US	West US 2

For up-to-date information about regions supported by Azure, see Azure Regions.

 

Read-access geo-redundant storage

Read-access geo-redundant storage (RA-GRS) maximizes availability for your storage account, by providing read-only access to the data in the secondary location, in addition to the replication across two regions provided by GRS.

When you enable read-only access to your data in the secondary region, your data is available on a secondary endpoint, in addition to the primary endpoint for your storage account. The secondary endpoint is similar to the primary endpoint, but appends the suffix –secondary to the account name. For example, if your primary endpoint for the Blob service is myaccount.blob.core.windows.net, then your secondary endpoint is myaccount-secondary.blob.core.windows.net. The access keys for your storage account are the same for both the primary and secondary endpoints.

Considerations:

·        Your application has to manage which endpoint it is interacting with when using RA-GRS.

·        Since asynchronous replication involves a delay, in the event of a regional disaster it is possible that changes that have not yet been replicated to the secondary region will be lost if the data cannot be recovered from the primary region.

·        If Microsoft initiates failover to the secondary region, you will have read and write access to that data after the failover has completed. For more information, please see Disaster Recovery Guidance.

·        RA-GRS is intended for high-availability purposes. For scalability guidance, please review the performance checklist.

Premium Storage

·        Premium Storage supports only locally redundant storage (LRS). For information about Premium Storage, see Premium Storage: High-Performance Storage for Azure Virtual Machine Workloads.

Best Practice Analyzer for Forefront Identity Manager 2010 R2

In Forefront Identity Manager 2010 R2 management, best practices are guidelines that are considered the ideal way, under normal circumstances, to configure a server as defined by experts. While best practice violations, even critical ones, are not necessarily problematic, they indicate server configurations that can result in poor performance, poor reliability, unexpected conflicts, increased security risks, or other potential problems.

Topics in this section can help you bring FIM 2010 R2 running on Windows Server® 2008 R2 into compliance with best practices. Content in this section is most valuable to administrators who have completed a Best Practices Analyzer scan of FIM 2010 R2, and who want information about how to interpret and resolve scan results that identify areas of FIM 2010 R2 that are noncompliant with best practices.

For more information about Best Practices Analyzer and scans, see Best Practices Analyzer.

FIM 2010 R2 BPA Pre-requisite Software

The Forefront Identity Manager 2010 R2 Best Practice Analyzer requires the Microsoft Baseline Configuration Analyzer 2.0 or later before it can be installed and run. The Microsoft Baseline Configuration Analyzer 2.0 (MBCA 2.0) can help you maintain optimal system configuration by analyzing configurations of your computers against a predefined set of best practices, and reporting results of the analyses. Best practices are developed by a product development team or domain experts, and are packaged in the form of a best practice model.You can download the Microsoft Baseline Configuration Analyzer 2.0 here (http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=16475).

FIM 2010 R2 BPA Pre-requisite Tasks

In order to use the FIM 2010 R2 BPA you must ensure that Windows PowerShell Remoting is enabled on the server or servers that you wish to run the Best Practice Analyzer against. For more information on Windows PowerShell Remoting see Enable-PSRemoting.

FIM 2010 R2 BPA Installation

To install the FIM 2010 R2 BPA use the following procedure.

To install the FIM 2010 R2 BPA

1. Open a command prompt with elevated permissions, navigate to the directory that contains the FIM2010R2BPA.msi and enter the following:
   msiexec /i FIM2010R2BPA.msi /l*v c:\FIMBPALOG.txt
   

   This will start the installation wizard and creates a log file in case there are any issues with the installation.
2. On the welcome screen click next.
   
3. On the EULA screen, read the EULA and if you accept place a check in the I accept the terms in the License Agreement checkbox and click Next.
4. On the Ready to Install screen click Install.
5. Once the installation has finished, click Finish.

Using the FIM 2010 R2 BPA

To start the FIM 2010 R2 BPA use the following procedure:

Using the FIM 2010 R2 BPA

1. Click start, select All Programs, and select Microsoft Baseline Configuration Analyzer 2.0. This will bring up the Microsoft Baseline Configuration Analyzer 2.0.
2. In the drop-down under Select a product, select Forefront Identity Manager 2010 R2 BPA.
   
3. Click Start Scan.
   
4. Once the scan has completed any Non-compliant rules will appear under the Noncompliant tab. Under the All tab you can view all of the Compliant rules.
   
5. You can also view the data that was collected by selecting the Collected Data radio button.
   
6. At this point you can export the report to XML.

FIM 2010 R2 BPA Parameters

The following table is a list of parameters that can be set when using the FIM 2010 R2 BPA.

Name	Description
Alternate_Server_to_Scan	The server that you want to run the scan against. You can use either the NetBios or the FQDN of the server. Example: APP1 or app1.corp.contoso.com.
Database_Name_For_Database_Scan	The name of the database you wish to scan. This can be left blank and you can simply enable Analyze_FIM_Service_Database and Analyze_FIM_Sync_Service_Database.
SQL_Server_Instance_Name_For_Database_Scan	The name of the SQL instance that the databases are running under. If nothing is specified then the default instance will be used.
Analyze_FIM_Service	Compares the current environment with the best practices for the FIM Service. To enable this select the checkbox.
Analyze_FIM_Service_Database	Compares the current environment with the best practices for the FIM Service Database. To enable this select the checkbox.
Analyze_FIM_Sync_Service	Compares the current environment with the best practices for the FIM Sync Service. To enable this select the checkbox.
Analyze_FIM_Sync_Service_Database	Compares the current environment with the best practices for the FIM Sync Service Database. To enable this select the checkbox.
Analyze_FIM_Certificate_Management	Compares the current environment with the best practices for the FIM Certificate Management. To enable this select the checkbox.
Analyze_BHOLD	Compares the current environment with the best practices for BHOLD. To enable this select the checkbox.

More information about Forefront Identity Manager 2010 R2

Common identity is an important tool in ensuring your users have appropriate access to corporate information. Without an efficient method of establishing and maintaining a common identity across complex heterogeneous systems, significant challenges arise. These can include high help-desk costs for password resets and smart card deployment, loss of productivity as users struggle to access the resources they need, and serious risk to the business due to noncompliance with internal and external regulations.

Microsoft Forefront Identity Manager (FIM) 2010 R2 helps you resolve these issues by providing self-service identity management for your users, automated lifecycle management across heterogeneous platforms for your administrators, and a rich policy framework for enforcing corporate security policies and detailed audit capabilities.

FIM 2010 R2 integrates new functionality through the Microsoft BHOLD suite to provide role-based access control and allow administrators to review access rights continually across the organization. The FIM 2010 R2 release also adds an improved self-service password reset experience, along with performance, diagnostic, and reporting improvements.

For more information about FIM 2010 R2, see Forefront Identity Manager 2010 R2.

Product Category for System Center in WSUS

New product family to your WSUS server today – System Center. The System Center product family will contain updates for versions 2012 and higher of System Center products, which include System Center 2012, a product that combines components such as:

• Operations Manager
• Configuration Manager
• Data Protection Manager
• Service Manager
• Virtual Machine Manager
• Endpoint Protection
• Orchestrator
• App Controller

The System Center product family will allow a variety of update types, e.g. service packs, optional updates, critical updates, and security updates. System Center updates will also be available in the Microsoft Update Catalog at http://catalog.update.microsoft.com.

You will see new product categories appear under the System Center product family as new updates are available for each product or product component. The first product category to be added will be System Center Advisor. For additional information about System Center Advisor, see http://www.SystemCenterAdvisor.com/.

We encourage you to synchronize the System Center product family if you are planning to deploy System Center 2012, either through upgrades or new licenses, or if you already have System Center 2012 products in your managed environment. For additional information about System Center 2012, see http://www.microsoft.com/en-us/server-cloud/system-center/default.aspx.

Error installing SCCM MP Point in domain controller...

 

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN

3. In the right pane, right-click DependOnService, and then click Modify.

4. In the Edit Multi-String dialog box, type Netlogon in the Value data box, and then press ENTER.

5. In the Value data box, type DNS, and then press ENTER. The contents of the Value data box appear as follows:

RPCSS
SamSS
Netlogon
DNS

6. Click OK, and then exit Registry Editor.

Active Directory Health Checks for Domain Controllers

 

The Event Viewer is always a must to checked.

Dcdiag.exe /v >> c:\temp\pre_dcdiag.txt
Will tell you if there is trouble with your DCs and/or services associated with it .

Netdiag.exe /v >> c:\temp\pre_Netdiag.txt
This will let me know if there are issues with the networking components on the DC. 

Netsh dhcp show server >> c:\temp\pre_dhcp.txt
This allows to verify the server count and names.

Repadmin /showreps >> c:\temp\pre_rep_partners.txt
This shows all replication and if it was successful or not. 

repadmin /replsum /errorsonly >> c:\temp\pre_repadmin_err.txt
This is the one that always takes forever but will let you know who you are having issues replicating with.