What are the best practices for ADFS disaster recovery plan with specifications as below:
2 Different ADFS FarmsFarm
1 :- ADFS 2012 farm with SQLFarm
2 :- ADFS 2012 farm with WID database.
To setup ADFS Disaster Recovery Site
There are 2 options to do this, which will give some idea on your scenario.
Scenario: ADFS Farm (ADFS Servers, Proxy) setup on Azure, which need similar setup on another region to prepare for Disaster recovery.
Plan A : Create a ADFS server and WAP server in the DR site and join to the existing Farm.
Create 2 Azure VMs in the DR site
Make sure the 2 VMs are able to communicate over port 443
Make sure the server for ADFS is joined to the same domain and has a line of site to your domain controllers (TCP ports 80 & 443)
Make sure the server of ADFS is able to communicate with your existing primary ADFS server over TCP ports 80 & 443
Install the ADFS server role and configure it to join the existing ADFS farm
Install the WAP server role and complete the configuration wizard to build up the WAP trust with ADFS
In the DR failover drill, modify the internal/external DNS record to point to the DR site ADFS/WAP server and test if the authentication service is working.
You can shutdown the servers on DR site afterwards, please make sure to boot up the machines when there are configuration changes on your production servers to sync up
Plan B : Use ADFS Rapid Restore Script to back up existing ADFS server and quickly restore later
Install the MSI on your existing primary ADFS server
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-rapid-restore-tool
Backup the current ADFS service to a protected file system or even Azure Storage Container using PowerShell commands like below
Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\Users\administrator\testExport" -EncryptionPassword "password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM
The backup file will be named to the pattern "adfsBackup_ID_Date-Time"
You can schedule a task to run this back up from time to time so there will always be an up to date back up
In case anything happens, create a new Windows Server with the same OS version, join it to the same domain and leverage the same PowerShell module to restore from back up
This tool can only back up ADFS service, you need to add another server, install the WAP role and re-configure the trust following the wizard.
Reference To Create and customize recovery plans : https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-create-recovery-plans
Related
If I use one of the methods to migrate a SQL server instance with several databases into a Azure Managed Instance, would the procedure also replicate any login accounts with access rights?
Particular interested in knowing how this handles Active Directory accounts
From what I know, it doesn't and you cannot use Windows Authentication but only SQL Server Authentication or Azure AD. I've migrated several times a local database of my local SQL Server instance to Azure and I've done it using Export Data-Tier to .bacpac (this is the extension of the DB in Azure) and then deploying it (both actions from SSMS):
However, please be aware that you have to drop any users that use for authentication Windows Authentication because you'll get an error at the moment of deploying it since it cannot inherit your server's active directory settings. Then, you can define your own AD in Azure and use it.
Managed instance is a new deployment option of Azure SQL Database, providing near 100% compatibility with the latest SQL Server on-premises (Enterprise Edition) Database Engine.
The migration only support replicate the login.
You could get this from this document: Tutorial: Migrate SQL Server to an Azure SQL Database managed instance offline using DMS:
By default, Azure Database Migration Service only supports migrating SQL logins. To enable support for migrating Windows logins, see the Prerequisites section of this tutorial.
That means you must re-create all the users and grant it access right(database roles) manually.
Hope this helps.
I have an Azure VM (windows Server 2016 and SQL Server 2016) running a production web app that serves as both the app and db server for performance and cost reasons. There is some corruption that has caused various issues like windows updates fail, SQL Server auto patching fails, can't open SQL Server Configuration tools, etc. I'd also like to upgrade from SQL Server to a newer version (2019) for some features.
I've read that it is not possible to do an in-place version upgrade, so the recommended path is to spin up a new VM with the latest SQL image and migrate from the old to the new. I know that link is for an Edition upgrade, which it seems they now do support. But I haven't seen this as being possible on version upgrades. As such, I assume migration is still the path?
I have 2 data disks on the current VM to house the data and log files that I can move over to the new VM...but there are a lot of other aspects to consider like public IP, network security group, SSL Certs, IIS config, etc.
I'm an app developer, not a windows admin, and new to Azure as well. Are there any check lists on how to do this as painlessly as possible? My google searches were fruitless (got moving to different regions, migrating from SQL server to Azure SQL, etc). For example, create the new VM, move the data/log disks over to the new VM, restore the DB on the new VM, script out SQL jobs/logins from source to new, point the external IP and NSG to the new VM, manually create IIS websites and reinstall SSL certs....
As far as I know, currently, you still need migration VM for SQL version upgrading as that answer explained.
In fact, you have found the main steps in the migration path. You will backup your important data and logs, backup the DB and the web app, export the SSL certs. Then you will create the SQL virtual machines with a new image SQL server 2019 on the Azure portal. Then you will import the SSL certs and configure IIS websites, restore the DB on the new VM, script out SQL jobs/logins from source to new.
When you create the new Azure VM, you can deploy the new VM in the same region and subnet as the old Azure VM, you can also attach the new Azure VM with the old subnet level NSG. Optionally, a new public IP will be assigned to the new Azure VM, you will use this new Public IP to connect to your web app and DB. After validating the deployment, installation, and configurations. You can remove the old Azure VM, Network interface, old SQL OS and data disks.
For more information:
Migrate a SQL Server database to SQL Server in an Azure VM
Associate network security group to subnet
Move or copy an SSL certificate from a Windows server to another Windows server
I am taking a Windows Azure introductory course and one of the prerrequisites for it is to have installed SQL Server 2008 R2 on my machine.
When I'm installing SQL Server in the Server Configuration section it asks for 2 users: one for the SQL Server Agent and other one for the SQL Server Analysis.
I am a begginer, so that's why I'm asking you to recommend me wich users should I use. And also, is it possible to change the users after installation?
Thanks in advance.
Yes, you can change the user after you install those services. The services will run using those accounts and therefore the services will have the same rights as the accounts.
For DEV/test you can use the local system account.
For production you should create a dedicated domain account for those services.
The best account to use in this instance would be The Network Service Account.
Be aware that the Local Service account is not supported for the SQL Server or SQL Server Agent services.
The Network Service account is a built-in account that has more access to resources and objects than members of the Users group. Services that run as the Network Service account access network resources by using the credentials of the computer account. The actual name of the account is "NT AUTHORITY\NETWORK SERVICE".
Network Service Account is the only account which is supported by SQL Server and SQL Server Agent Services, allows for network file system access i.e. SSMS DBA tasks, and yet still avoids using a Local System Account.
http://msdn.microsoft.com/en-us/library/ms143504(v=sql.105).aspx
To change which account the service runs under, do so in the same GUI that you are currently using inside SQL Server Configuration Manager
I am trying to use IIS 7.5 Application Pool identity as login on SQL Server 2008 R2 so that my ASP.NET web app can connect to the database...
Using this approach worked fine on my local dev machine (IIS 7.5 and SQL Server 2008 R2 on same machine).
However, when I try to set up the same on production (IIS and SQL servers are separate) I am unable to add "IIS APPPOOL\MyAppAppPool" login to SQL Server 2008 R2.
Notice that in either case you cannot use "Browse..." when creating a login in SQL Server since "IIS APPPOOL\MyAppAppPool" user identity is dynamic (or "special")...
Any ideas?
Update:
For more info on Application Pool Identities see here.
From article:
Whenever a new Application Pool is
created, the IIS management process
creates a security identifier (SID)
that represents the name of the
Application Pool itself. For example,
if you create an Application Pool with
the name "MyNewAppPool," a security
identifier with the name
"MyNewAppPool" is created in the
Windows Security system. From this
point on, resources can be secured by
using this identity. However, the
identity is not a real user account;
it will not show up as a user in the
Windows User Management Console.
That articles states (under "Accessing the Network") you still use the <domainname>\<machinename>$ aka machine account in the domain.
So if both servers are in "foobar" domain, and the web box is "bicycle", the login used to the SQL Server Instance is foobar\bicycle$
If you aren't in a domain, then there is no common directory to authenticate against. Use a SQL login with username and password for simplicity
Edit, after comment
If the domains are trusted then you can use the machien account still (use domain local groups for SQL Server, into which add a global groups etc)
As for using app pool identities, they are local to your web server only as per article. They have no meaning to SQL Server. If you need to differentiate sites, then use proper domain accounts for the App Pools.
You can't have it both ways...
I have a remote MSQL instance that I want to use with biztalk. My machine running biztalk cannot join the same domain as the MSSQL instance, nor can we create a trust relationship between the two windows domains.
Is there a way to configure biztalk to authenticate? Username/password (like any other DB would use) would be perfectly fine.
If you're talking about using the SQL Server as the primary data tier for your BizTalk installation, then maybe. There's an old trick where you create local accounts on both servers with the sam credentials (id & password) and then use the local account for your services. This is hacky and not reccomended.
As far as the SQL Server Adapter, just provide the credentials in the conneciton string. Caould be a SQL Account or a remote domain account.