How Does Theming Work in ADFS?

1. Logo (image).
2. Illustration (image).
3. Stylesheet (CSS).
4. Runtime stylesheet (CSS).
5. JavaScript to run “on load”.
6. Additional file resources.

New-AdfsWebTheme -Name "umbrella-theme" -SourceName default Set-AdfsWebTheme -TargetName "umbrella-theme" -AdditionalFileResource  @{Uri="/adfs/portal/images/caution.PNG";Path="S:\Umbrella-ADFS-theme\images\caution.PNG"} Set-AdfsWebTheme -TargetName "umbrella-theme" -AdditionalFileResource  @{Uri="/adfs/portal/images/UmbrellaBack.jpg";Path="S:\Umbrella-ADFS-theme\images\UmbrellaBack.jpg"} Set-AdfsWebTheme -TargetName "umbrella-theme" -StyleSheet @{Locale="";path="S:\Umbrella-ADFS-theme\css\style.css"} Set-AdfsWebConfig -ActiveThemeName "umbrella-theme"

PHP has been an option for an Azure web-app runtime for a while now as you may have noticed already:

That’ll give you IIS with PHP configured through FastCGI. Read more about how it’s setup @ https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-php-configure if you want.

There is a Linux option too for full LAMP as a service, but I’ve not looked in it yet.

What is Azure App Services?

If you’re wondering what app services even are, here’s my own, brief explanation with the official explanation here.

App Services is “platform as a service”, for anything web-server related. What that means in reality is you don’t have to worry about managing the underlying machines that run your code; we (the Azure guys) are responsible for that, and you just focus on your code. It’ll “just work”!

More specifically, we’ll handle patching, uptime, load-balancing, core OS configuration, etc, etc; you just have to make sure you’ve configured your “app service” the way you want – what code is on it, what logging & monitoring you want to see.

For performance vs cost, you say how much it needs to scale vs how much money you want to spend. There’s all sorts of options for scaling automatically, manually, on a schedule, etc, etc. Free is an option, but obviously that’ll go rather slow if anyone actually hits the website in any real amount.

MySQL in App

Something available in App Services is something called “MySQL in App” which is a cost-effective way of getting MySQL running. Here it is:

I say cost-effective because of how MySQL runs, which is basically within the same virtual-machine that also runs the PHP code, so you don’t have to pay any more for a database tier.

Obviously, this limits scalability quite significantly; you’re sharing the same CPU & memory with IIS/PHP, but it is cheap. Free even, if you run the free service-tier.

Want to scale-up? You can offload the MySQL part to Azure Database for MySQL and scale as much as you want. Azure Database is “database as a platform”, and now there’s a MySQL flavour too.

Running MySQL under IIS

So, the first thing to realise about MySQL in App is it runs within the context of IIS itself, hence the “in app” part.

Here we see a MySQL log-file from a MySQL process that’s just been spun-up:

Note the process ID of MySQL…

Now if we check out the environment process-explorer in Kudu (available under the “advanced tools” blade in the portal):

Also notice “mysqld.exe” is running under w3wp.exe (IIS worker process).

This is fairly significant; it means that is we have no IIS worker-process, we have no database in the “MySQL in App” setup. That in turns means, if nobody’s hitting the site, we have no database running! See below for why & how.

Also worth noting, and this is a potentially big deal for production sites especially, the “free” tier in app-services doesn’t give you the App-Services “always on” setting. This means IIS will eventually unload itself after a certain amount of activity…unloading your database engine with it.

That is until someone hits the site anyway, which will trigger a new worker-process and start-up another MySQL instance too.

phpMyAdmin on App Services

phpMyAdmin is a very popular admin tool for MySQL and if you’re running “MySQL in App” then you actually already have it installed, despite phpMyAdmin being an extension you can install.

Click on the “MySQL In App” blade and you’ll see the config + a link to the pre-installed phpMyAdmin via the “manage” button.

Clicking that will open phpMyAdmin. It’ll open on the admin “SCM” URL for the website (i.e. be secured the same way Azure portal is).

Interestingly, if you’ve not hit the website yet & spawned an IIS worker-process then MySQL won’t be running, and you’ll hit a connection error:

Hit the website; that’ll spawn a worker-process + MySQL, and then phpMyAdmin should now work.

Pro-tip: don’t install the phpMyAdmin extension if you have the “MySQL in App” option already. Seriously don’t; you’ll kill the nicely pre-configured instance.

Connection String to MySQL

Where’s the connection-string for PHP then? Having played around with the WordPress App Services template, this is where it seems to be:

Opening the file & here’s the string:

Sharper-eyed readers may have noticed above; this connection-string is normally available via environment variable “MYSQLCONNSTR_localdb”, which is what WordPress at least uses for its connections to the database.

Transferring Files into App Services

Finally, as this is a bit of a n00b article, how do we get files on & off the website?

GitHub integration is probably the best way, but if you want a more traditional way too FTP is an option.

Configure deployment credentials first:

Then, download the publishing profile:

That’s basically an XML file with various ways of publishing files to the app-service, one of which is the FTP method:

(and yeah, this was a throwaway app-service, so don’t try and connect :P).

Lo & behold, the server files:

Upload & download to your hearts’ content!

That’s it for now - cheers!

// Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/excel-data-connection-refreshes-in-sharepoint-2016-office-online-2016 Tue, 25 Apr 2017 16:59:20 GMT https://blogs.msdn.microsoft.com/sambetts/?p=2495 Here’s a quick run-through on how to refresh data connections in Excel files stored in SharePoint, via Office Online, 2016 edition.

Things have moved around in SharePoint 2016; no longer does Excel services exist in SharePoint-land, so refreshing Excel data-sources on the web has changed a bit. This is a quick guide on how to get the same setup in the year of our Lord, 2016 AD.

What’s a Data Connection in Excel?

Something that some customers like to do is connect to SQL Server or other data sources within Excel files. This way you can have your Excel file magically update its data from a central repository, and it’s all very nice.

The challenge arises when we move that same Excel file into SharePoint and except that same data refresh functionality to work the same. In Excel, it’s pretty straight forward; excel.exe is running under your identity so when it connects to SQL Server for example, it already has all the credentials it needs to do a refresh. Here’s the example we’re going to use:

Behold, data from SQL Server via the power of data connections. Refreshes from Excel work without much drama.

The problem with moving this into SharePoint however is that SharePoint isn’t running as “you” but needs to pretend to “be you” if the same data refresh is going to work.

Here’s the architecture in SharePoint & Office Online 2016 for a typical data refresh:

The difference here is our claims-to-Windows token service is configured in Office Online, although there’s still the same service in SharePoint too – ignore it for now.

Network Setup & Configuration

Here’s the relevant details for my own setup then.

SQL Server is running under an account “awesomecloud\svc_sql”. It has these registered SPNs:

On the Office Online server, Claims to Windows Token is running as local system:

Running as local system saves a bunch of local security policies that a domain account would need to add (“impersonate a user”, “act as part of the OS”, and more). Just run as local system & save some headaches.

As we are running C2WTS as local system, the Office Online *computer* object is given delegation access to the SQL Server SPNs:

Unconstrained delegation no less. We need this so we can then impersonate $loggedInUser to SQL Server for our refresh.

Next up, the C2WTS needs to allow invocation by Office Online server. Do this by editing the file “C:\Program Files\Windows Identity Foundation\v3.5\c2wtshost.exe.config”.

Uncomment the line:

<add value="NT AUTHORITY\Network Service" />

The file should look something like this:

<allowedCallers>

<clear/>

<add value="NT AUTHORITY\Network Service" />

<!-- <add value="NT AUTHORITY\Local Service" /> -->

<!-- <add value="NT AUTHORITY\System" /> -->

<!-- <add value="NT AUTHORITY\Authenticated Users" /> -->

</allowedCallers>

Save & restart the service. Now refreshes from Excel Online should work!

An Excel Data-Connection Refresh in Action

Assuming everything is working, this should now be possible. Here we open an Excel file, same one as above in fact, in SharePoint/Office Online. Refreshing the connections should not only not give us any errors, it should also now reflect any new data in the table.

…and the result…

This is the end-goal here; data refreshes just happening. If you checked on the SQL Server, as far as it was concerned, the refresh query would’ve executed under my logged-in Windows account equivalent – no claims here I’m afraid.

Stuff to Remember

It’s quite likely though you’ll hit some road-blocks on the way to getting it working. Here’s a few tips & clarifications.

Firstly, the C2WTS call uses Kerberos but authentication to SharePoint with Kerberos isn’t necessary. I did this connecting via NTLM to SharePoint just to prove a point. Double-hop isn’t happening or needed.

Why? Because SharePoint is all claims-based for authentication; Kerberos or NTML or whatever will just end up as a claim to SharePoint; one that’s then passed to Office Online.

That claim is then turned back into a Windows token, coincidentally using Kerberos to do so, but there’s no classic Kerberos double-hop happening here.

Next, Kerberos is actually used however to impersonate the logged in user to the service being connected to – SQL in this instance. C2WTS will request a ticket to do so, and if the right SPNs & delegation isn’t setup, it’ll fail. To make matter worse (and I’ll be honest, I’m not 100% clear why being that Kerberos isn’t my speciality), that response is cached to some extent even if you then fix the initial problem. So in other words, if you’re certain something should work – restart the Office Online server and it might just work next time you try.

When it does work, you’ll see the result if you look at SQL Server profiler:

My user is connecting to SQL Server, despite me not being on the Office Online server itself – just logged in to SharePoint which uses Office Online server to do it’s refresh work. Clever!

Finally, Office Online server has ULS logs, just like SharePoint. Run “Get-OfficeWebAppsFarm” to find out where they are & use them for if & when this doesn’t work.

That’s it for now!

Cheers,

// Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/sharepoint-web-application-proxy-2016-edition Tue, 04 Apr 2017 15:46:51 GMT https://blogs.msdn.microsoft.com/sambetts/?p=2355 I’ve done a couple of articles already on Web Application Proxy (WAP) with SharePoint, and figured it was time to update the series now Windows Server 2016 has improved on it. Here’s how to set-up SharePoint 2016 with Windows Server Web Application Proxy 2016, up, high-level.

First, a quick recap; why use WAP on-top of SharePoint & ADFS? Because it gives you a way of exposing your public SharePoint applications to the internet without anyone having any line-of-sight. This is important because it means nobody could overwhelm your SharePoint infrastructure without being authenticated first.

The idea is WAP sits in a DMZ, can be completely unconnected to any domain even, and just forward requests to SharePoint once a valid ADFS token has been gotten.

This is very nice as we can isolate our precious production servers from any direct contact from outside.

Also, WAP gives us extra authentication options for ADFS Server – we can insist on different security policies depending if the user has come from externally or internally.

How does ADFS know if a user is external or internal? Simple – a user request either came via the proxy or it didn’t.

New Things in 2016

So what’s new then? On the SharePoint side, not much as far as ADFS/WAP is concerned.

In WAP though we can now do things like:

• Use single wildcard certificate for publishing applications. Much easier for things like SharePoint-hosted apps which have unique domain-names per app.
• Redirect to HTTP back-ends (HTTPS no longer required).
• Some other stuff.

All in all, quite a worthy upgrade for Windows Server Web Application Proxy.

Network Requirements

The network setup is key to the whole thing working.

As our Web Application Proxy will be the contact point for all traffic both to SharePoint & ADFS, it needs to have the same SSL certificates & IP associations as internal SharePoint addresses do. Behold, figure 1:

WAP needs to be the external contact-point for everything needed internally; SharePoint & ADFS too.

It’s true though that SharePoint doesn’t necessarily need the same DNS names internally & externally, but I’d highly recommend it for simplicity sake – alternative access mappings are a pain. Some network guys like to have visibly different internal & external URLs, but frankly it only causes headaches for SharePoint URLs – things that work inside the network magically don’t work outside, etc.

Keep URLs the same please! Seriously…

SharePoint Security Configuration

For my tests, I’ve taken an internal ADFS-secured SharePoint web-application & simply published it externally. It is possible to have WAP convert ADFS tokens into internal Kerberos tokens for standard Windows-authenticated SharePoint web-apps instead, but I simply can’t be bothered with protocol transitioning. Why? Because ADFS is simply a better security solution that Windows auth directly on SharePoint web-applications, and ADFS can authenticate with Windows auth anyway.

ADFS published websites are the way to go; forget native Windows authentication for SharePoint web-apps – you’ll be doing yourself a favour in the long-run, IMO.

Why Use ADFS Instead of Windows Auth for SharePoint?

ADFS give you a lot more control over identities. First, you can set what the “ID” (identifying claim) of each user will be; account-name, email address, whatever you want.

Second is that, with the claims sent to each application (SharePoint in this case) we can manipulate them before sending them to the client-app (SharePoint) if we want too. This can make things like domain-mergers much easier; users from a newly absorbed domain can appear to SharePoint like users in another domain for example.

Third, is the extra security you have for authentication. Multi-factor-authentication is possible for users based on certain policies, etc.

Oh, and single-sign-on for Office 365/Azure AAD can use it.

In the end, SharePoint isn’t designed to handle authentication & identity policies; ADFS is and does it very well. SharePoint & ADFS complement each other very nicely.

Use it!

Publishing a SharePoint Web-App

So first up then let’s make sure the network is working – ping/nslookup from inside & outside the network and verify the IP addresses are correct for each address, in all networks (internal, DMZ if you have one, and outside on the internet).

Then get your certificates installed on your WAP 2016 machine(s). Obviously WAP needs line-of-sight to your ADFS instance too. Do not continue until you have this infrastructure verified.

Now install the Web Application Proxy role. Configure the ADFS server being used.

Finally publish your SharePoint application in WAP like so.

That’s it!

Assuming your network setup is correct, clients should now be using WAP for all requests, and it’ll just work.

Testing for Proxy Usage

You can tell if you’re hitting a WAP server instead of the real end-point from this header:

Here’s a normal response if you’re going direct to SharePoint:

That’s it!

// Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/super-sql-server-clusters-for-sharepoint-part-2 Mon, 05 Dec 2016 15:22:55 GMT https://blogs.msdn.microsoft.com/sambetts/?p=2175 This is part two of one of how to setup the mother of all database clustering solutions for SharePoint. In part one we setup the failover cluster, installed SQL Server and configured the failover clusters.

Previously we’d setup our super-cluster & installed SQL Server, this time with two failover clusters; one for each farm.

Now we need to setup or create our SharePoint databases for both the primary & secondary farms.

Create SharePoint Databases for Each Farm

At this point we should have all of our SQL instances ready to go. Next we need to add the databases so we can setup AlwaysOn for those databases.

Using client-side SQL aliases, this is what we want to build first:

Both farms have separate configuration & some service apps where it makes sense (seriously, this is important). For anything we’re going to copy between farms like content-databases for example, we’ll just create/move the databases onto the primary farm.

First create/edit a SQL alias on each SharePoint server:

Create new farms; one on each failover cluster for each farm, using said alias:

…or use PowerShell if you prefer.

You could just as easily move databases if you already have SharePoint farm(s) setup already; the principal is the same – we want two farms working, each one on a separate failover cluster.

Create Service-Apps

Once we have two farms setup & ready we need to create the service-apps next.

Create & configure your service-applications as needed on the primary farm. Leave the secondary farm as we’ll use copies of everything from the primary farm, with one exception…

Each farm should have its own separate search application + databases.

Search isn’t something that you want to copy between farms as we want farm redundancy on this huge chunk of SharePoint, so we’ll just fail it over to the local farm SQL instances.

Create Content Databases & Web-Applications

Also as before, create a web-app on the primary farm only with either new or restored content databases.

Create AlwaysOn Availability Groups for SharePoint Farms

At this point we should have all of our SQL instances & databases ready to go for both SharePoint farms.

Now we have to create the availability-groups for them – we want the following SQL Server AlwaysOn availability groups:

• Farm-local failover groups.
  • All the databases that won’t ever move between farms, one group per farm.
• Service application availability group.
  • All service-app data that both farms will share, copied between the two farms.
• Content database availability group.
  • All the content that both farms will share, copied between the two farms.

Now, it should be pointed out that creating AlwaysOn availability groups is much (so much) easier when the database file paths are exactly the same across all instances. If this is the case, you can perform an initial “full” sync via a shared network path to backup & restore the databases + transaction-logs.

Otherwise you need to do the DB + transaction-log restores manually & just have SQL Server join the databases. This my friends, is an epic amount of work if you have to do it by hand.

Farm + Search Availability Groups

We need two farm AlwaysOn availability groups; one per farm so we have farm redundancy. That means we’ll have two copies of each farm database & two SQL instances we can use, with at least one instance with two member servers.

We want the config DB, central admin content + the search databases in this group. All need to be in “full recovery” mode, so just make a backup of each database and they should be ready to add. Add the state service DB too if you have one.

We don’t care too much about the usage database because it can be very heavy on updates, and isn’t critical.

Here we’re including the state service in the local farm group, meaning it won’t be synced between farms. This is because I don’t have any SharePoint 2010 style workflows so isn’t needed to be synced, but your requirements might differ (read: if you have workflows, don’t include the State Service DB in the local farm group – sync with service-apps DBs).

Next up; add the secondary replica for our local farm failover AG, which in farm 1s’ case is “SQL-N1”.

Now we need to join the databases. In my specific setup we can’t do a full sync here as both SQL-N1 & SQL-N2 use different paths for the database files (something you can technically avoid if you know ahead of time, but I forgot).

Anyway, as mentioned earlier, the alternative is the somewhat-more-hassle restoring each database with no recovery (important) on the secondary so the wizard can just join each DB to the availability group instead of creating each one too.

Join only a pain to get DBs in sync, but nobody said this will be easy. Assuming all the databases to add are ready on the secondary instance (SQL-N1 in this example), in “restoring” mode then this will work no problem.

Create availability group “SPFarm1” between instances SQL-N1 & SQL-N2, and another availability group “SPFarm2” between SQL-N3 & SQL-N4.

Service-Apps Availability Group

Next up, we want another separate availability group for service applications. On farm 1 create/mount the following service applications:

• Managed Metadata
• User profiles
• App Management
• Secure Store
• …
• Whatever service-apps you use that have databases that need syncing.

Once created & working, create a new availability group between SQL-N2 & SQL-N3 to synchronise the databases in those applications, except the sync DB for user profiles.

Once mounted, primary to SQL-N3 & in farm 2 add the service-applications using the existing databases setup in AlwaysOn.

More on sharing service-apps between farms @ https://blogs.msdn.microsoft.com/sambetts/2016/03/21/running-sharepoint-service-applications-in-read-only-mode-for-disaster-recovery-farms

Content Database Availability Group

Finally do the same again for content databases as you did for service-apps in a 2^nd group between SQL-N2 & SQL-N3, just with the content databases. One new availability group between nodes SQL-N2 & SQL-N3.

Create Listeners & Update SharePoint Aliases

Now we just need to add listeners for the SPFarm availability groups so SharePoint will failover between the farm instances transparently.

I’ll add mine here; for some reason SQL doesn’t let me create one unless all possible subnets are covered, even though for the farm-specific connections were never going to cross a subnet.

Having a listener for each farm means either farm 1, for example should be able to use either SQL-N1 or SQL-N2 instances; the change-over will happen transparently.

Even better, as SQL-N2 is a failover cluster of two members, SQL-N2 itself could even failover to either SQL-N2-S1 or SQL-N2-S2 and again, nothing would change. Two levels of failover transparency! My goodness.

Anyway, to seal the deal, update each SharePoint farm server to use either “SPFarm1Listener” or “SPFarm2Listener” as we did before.

Everything Finished – Let’s Review the Setup

At this point your SQL Server cluster setup should look something like this:

• SQL-N1 (single member failover cluster)
  • SPFarm 1 availability group + listener.
• SQL-N2 (2-server failover cluster)
  • SPFarm 1 availability group + listener.
  • Service Apps availability group.
  • Content database availability group.
• SQL-N3 (2-server failover cluster)
  • SPFarm 2 availability group + listener.
  • Service Apps availability group.
  • Content database availability group.
• SQL-N4 (single member failover cluster)
  • SPFarm 2 availability group + listener.

You cluster host should now have no less than 8 roles in it:

Four failover SQL clusters & four availability groups. Clustering on steroids!

Testing Failovers & Outages

So this is the key goal here then; which SQL Servers can die without SharePoint suffering any outage? How many before we need to use the other farm?

No Farm Failover Needed

First let’s see what we can kill without needing to failover to the other farm.

We can technically keep working with up-to 4 SQL Servers offline & just 2 left, which is quite unlikely to ever happen. In this scenario we’ve lost two clustered roles too as there’s no servers left to run them. Assuming the two offline servers weren’t in the same failover cluster, we’d still have data-synchronisation between farms too.

Any one SQL Server can go offline without the slightest interruption of service, albeit we’d possibly have to failover the AlwaysOn AG manually, as automatic failover only works for standalone instances.

Farm Failover Needed

So what could go offline which would need an entire farm failover then?

In this case we have just one SQL Server running of the six setup, and even then we could still use the 2^nd farm. Synchronisation would be stopped but should in theory resume anyway.

Wrap-Up

Setting this kind of architecture up is very complicated, but as you can see it does give the benefit of having a zombie-like SQL backend for SharePoint – one that just won’t ever die.

In all honesty I’d only recommend this over SQL Server AlwaysOn for SharePoint DR if SQL/SharePoint uptime is absolutely critical, and so is guaranteeing data movement between SharePoint farms. In reality, it’s the guaranteed data movement that this model really gives over the standalone AlwaysOn for SP-DR model, but yet it’s quite a lot more complicated to setup.

Another negative is the lack of automatic failover between AlwaysOn instances, but as each instance is a failover instance itself that shouldn’t be an issue.

Anyway, in short, this is your solution if costs aren’t an issue & uptime is critical.

If you need an uptime solution for more reasonable costs, get AlwaysOn with just standalone instances.

Cheers,

Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/super-sql-server-clusters-for-sharepoint-part-1 Mon, 05 Dec 2016 15:09:28 GMT https://blogs.msdn.microsoft.com/sambetts/?p=1976 When I demonstrated AlwaysOn for SharePoint Disaster Recovery setups a while ago, the SQL cluster model I setup wasn’t strictly speaking highly-available. This is because there’s no failover for SQL Servers synchronising data between both SharePoint farms.

A couple of people have pointed this out now and as this is technically a potential fault, I wanted to expand on the previous design by turning the cluster design into a “super-cluster” (my own term). I wanted to build a SQL Server architecture to cover all the potential high-availability holes for SharePoint & the SQL backend. That and, well, any excuse to fire up some epic architectures is fine by me!

Before we begin, if this is your first time looking at AlwaysOn for SharePoint, you’d best read this quick overview first.

This is a two-part series just because of how big this setup guide is. We’re going to mount the backend for two SharePoint farms, with part one being the core cluster setup. Part two of the setup where we mount the SharePoint databases & availability-groups is here.

We’re going to setup said “super-cluster”; a cluster of clusters to some extent to serve two active/passive SharePoint farms just so we have God-like uptime & availability for SharePoint.

More specifically though, we have two goals for our super-cluster-architecture:

1. The most highly-available uptime for SQL Server known to mankind.
2. On the back of that, the most reliable content synchronising between our two SharePoint farms, also known to man.

This will be a complex setup, but still, it’s all so our users/bosses don’t complain SharePoint has gone down. If said bosses don’t want to commit to building this out then any failures aren’t a technology issue, but rather a financial one.

The Original SharePoint DR Architecture

Here’s our original SharePoint farms + SQL backend diagram:

As pointed out, this design isn’t actually as bullet-proof as it could be simply because a single SQL Server outage could bring down the primary SharePoint farm, unless everything was failed-over to the DR side, like so:

The same problem would be true if “SQL-N3” would go offline for any reason (patching for example); our AlwaysOn group for content will die and data synchronisation would temporarily stop, even if users won’t necessarily notice. This cannot be!

Even though we still do have high-availability in that we have failover options, it would be nice to further improve uptime even further by making sure our single server (“SQL-N2”) isn’t a point of failure for the main farm.

Side note: In fairness, AlwaysOn is pretty hot at resuming synchronisation when problems occur and service is resumed, but we want to make sure that isn’t necessary. In the case of “SQL-N2” going offline, it’s actually fairly serious because unless we fail-over to the other farm entirely we’re going to have fatal SQL exceptions.

The Solution: An AlwaysOn Cluster of Failover Clusters

In the above diagrams each server is just a standalone server in an AlwaysOn cluster. Back in the day, the only clustering in SQL Server was “failover” clustering which is somewhat different, but still available now.

The solution to fill this high-available gap is we’re going to make all the servers “failover clusters” with “SQL-N2” and “SQL-N3” specifically failover clusters with multiple members, instead of single servers. The other servers will also be failover instances too as AlwaysOn clusters can’t mix & match standalone & failover instances, but they’ll be failover instances of just one member. You could add more servers, but for now at least there’s no need.

Background: Failover Clustering

First though a quick bit of history. Failover clustering is basically clustering a single SQL Server service instance, while sharing data between the cluster members. Basically turn a standalone machine into several, with only one server pretending to the clustered server at any one time. If the active server goes offline (or we failover manually), the next failover server starts the SQL Server service and pretends to be the clustered server instead, using the same data files the previous server had.

Failover clustering is basically one service instance with multiple possible members. AlwaysOn is basically multiple service instances all together. The two work together quite nicely.

This is the new monster we’re going to create:

Yes indeed; this setup should satisfy even the most hardcore enterprise architects. We replace all the standalone instances with failover instances (albeit some instances with only a single member, for now); high-availably & maximum uptime in bag-loads. It’s quite a thing of beauty, if you like this sort of thing.

Creating a Super Cluster

So just for the lulz, I’ll show you how to create said super-cluster from scratch. If you had the previous model already you can just edit what you’ve got, but I’m doing it from zero just so it’s clear.

For this experiment, seeing as we’re in “enterprise: expert” mode, I created 6 SQL machines + 1 witness machine over 3 subnets – 3 machines are in one subnet, 3 machines are in another with the witness in the 3^rd subnet. Like this:

This gives a proper quorum, and one that’ll be designed to handle correctly network failures too.

For the SQL Service, we need a network account too – “awesome\svc_sql” in my case.

The failover machines also need some kind of shared storage between them. Ideally this should be shared SCSI disks, but in SQL Server 2012 and onwards you can use just a network path (which is much slower, so not recommended). My test lab has some limits, so I’m just using a network path for this, but be aware it’s really not that suitable for production setups normally.

Create Windows Cluster Host

In all 6 SQL Servers we need failover clustering Windows Server feature to be installed, and then to add each one to the parent host cluster. From one of the SQL Servers create a new cluster:

Next we need to validate the cluster. Normally for AlwaysOn this isn’t mandatory but for failover clustering, unless there’s a good validation report the setup won’t continue. Either way, you won’t get any support from Microsoft unless all tests are run (and passed) so run it.

So run the validation tests.

If you don’t validate, or have critical errors, SQL Server won’t setup as a cluster:

It’s fairly normal to have some warnings at least; proper clustering is an art-form but this is my dodgy test environment so, well, who cares. For production environments you should actually care.

Once done we should be able to create our cluster-host. This is just the host object for the entire cluster super-set. Clustered SQL Services will get added to it later on...

Finish the wizard, and now we can give the cluster host name.

As this is a multi-subnet cluster, we’ll need to give an IP address in each subnet as servers in either subnet could host the cluster-name-object in theory.

Now our cluster should show these nodes:

Now we’ll need to add a quorum to the cluster so we can make sure we failover correctly. We’re going to use the file-share on the witness machine on the 3^rd subnet. Right-click on the cluster root, “more actions” and “configure cluster quorum settings”.

Select “file share witness”; put the file-share path in:

Confirm, and that’s all the configuring you should do in the Cluster Manager now. Everything else, SQL Server will configure.

Install SQL Server on SQL Machines

Next step is to get SQL Server on each node. In AlwaysOn we can’t mix standalone & failover clusters so we’re going to add all 4 failover clusters, 2 of which have 2 members & the other 2 are just single-member clusters. That should be enough to demonstrate how this will work, and you can always add more member servers later.

Create New SQL Server Failover Clusters

We need to create here 4 new failover clusters, with SQL-N1 & SQL-N4 (our “standalone” machines) with a cluster of just one member.

I’m not going to go into detail about the process, as this technology is nearly as old as SQL Server, but here’s some details.

Installing a failover cluster isn’t like installing normal SQL; there’s a separate install method for failover clusters:

Run that and get started. This I did on “SQL-N2-S1” and “SQL-N3-S1” to create two new failover clusters. Most of the wizard is pretty straightforward, until the networking configuration:

Here I can only put an IP address in the top box because right now the cluster only has one member (this machine), hence multi-subnet configuration isn’t available yet. We’re not planning on making these roles multi-subnet however.

Another important detail: per parent cluster host, each service instance name has to be unique for failover instances at least. That means our failover clusters will technically be:

• SQL-N1\N1
• SQL-N2\N2
• SQL-N3\N3
• SQL-N4\N4

This is because we can’t have any two cluster instances as the default “MSSQLSERVER” (or just “SQL-N2” & “SQL-N3”). The instance name uniqueness seems a bit redundant but basically it’s because the service-names in the cluster have to be unique as well as the clustered object names (the virtual “server” name).

Also on storage for the database instance I’m using a network path because this is just a test environment so I don’t have the cash for proper SCSI discs:

This normally is a terrible idea though, just for performance reasons if nothing else – a network location, even with decent infrastructure, is many times slower than proper SCSI disks.

For the service account I’m still using “awesome\svc_sql” of course.

Create new failover clusters on machines SQL-N1, SQL-N2-S1, SQL-N3-S1, and SQL-N4; when done you should have four failover clusters of one server only each. We’re going to add the other servers in a minute.

Once you’re done, you should see the roles configured in the Cluster Manager:

Remember folks: don’t even touch anything here unless you know what you’re doing!

Configure Cluster Resource Ownerships

We need to check clustered that roles can only be taken ownership of by servers that should run the role. This isn’t just a good practise; SQL Server will fail when mounting the AlwaysOn availability group if this isn’t done right:

Anyway, in each clustered role, just uncheck any server that will never be able to run the role on the SQL Service so there’s no overlap:

In my case the service was set to allow SQL-N1-S1 too, even though it never could because it wasn’t a member of that failover cluster.

Seriously, get this bit right because SQL Server can really get its’ knickers in a twist if it gets halfway through creating an AlwaysOn availability group later & fails because these possible owners aren’t right – make sure each service can only be failed over to the server which are assigned to the instance.

Add SQL Server Failover Members

Now we have our failover clusters we need to add extra nodes to them so they can actually failover to something, for two of them at least. You could add failover members to all 4 technically, but as pointed out earlier, our high-availability vulnerable points are only really the SQL instances making up the availability group for content synchronisation, so here we’re only creating two “true” failover clusters. The others are single-member clusters because in AlwaysOn we can’t mix standalone & failover cluster instances into the same AlwaysOn availability group.

Anyway, to add a server to an existing failover cluster, we launch another type of installation:

This time there’s not so much to configure as it’s already been done; just what instance you want to join:

…and just confirming the IP address. In our case we’re not setting up a multi-subnet the failover instance we don’t have to do anything except join the existing configured clustered IP.

Also with the service-account; we can’t choose it as it’s done already, just add the password for this cluster node to save.

That’s pretty much it; the rest of the wizard will just join the server & install the service-instance.

Enable AlwaysOn on SQL Services

You’ll need to check this is on each primary or standalone server, in the SQL Server Configuration Manager:

Once you restart the service, that instance will be enabled for AlwaysOn.

Testing Failover Clusters

At this point we should have all our failover cluster resources ready, minus the AlwaysOn bits. Now’s a good a moment as any to test the failover clusters actually failover ok. It’s somewhat important to know our failover clusters can in fact, failover.

For failover clustering, failovers are transparent to SQL Server as opposed to AlwaysOn which drives the process from SQL Server itself (for the most part). Anyway, for failover clustering we use the Cluster Manager/PowerShell to drive events, rather than SQL Server itself.

Let’s check we can move each role to the other server. Open the Cluster Manager and move each one like so:

Normally we can just say move to “best possible node” which will use the possible owner configuration in the cluster to figure out which server could take the role, but we’ll do it manually…

This lets you select any node, but only nodes which have the service will actually work for the move command – trying to move a role to a server that isn’t allowed/configured for the role will give an error and not actually do anything.

Assuming you pick an appropriate server though, once you pick the other serer you’ll then see the cluster manager move everything there:

…and hopefully, if everything went well we’ll have a new owner for the clustered resource (SQL):

If there are any errors here, you’ll need to figure out why the other SQL node didn’t come up – application logs are a good start if the problem is the service. Sometimes though the problem can be cluster configuration (see below).

Do the same test for the other failover role.

Oops. Failover Cluster Fails to Actually Failover!

Testing your failover clusters can actually make the leap from one server to the other is kinda critical for obvious reasons. But if your test fails, this is what it’ll likely look like…

Clicking the “more information” menu shows us this:

So “sql-n3-s2” couldn’t accept ownership of the role for some reason or other. After poking around, it turns out the clustered IP address was misconfigured for some reason:

We’ve basically told the cluster that this IP address, which is a dependency for the failover role, can only be owned by one machine. Not much failover capacity here then, which is why it didn’t failover.

On investigating why in this example (this was a real slip-up on my part, not a faked problem) it turned out I’d forgotten to add SQL-N3-S2 to the failover cluster in the SQL Server Setup, so at the moment of testing “SQL-N3” really only had one possible server. What a n00b!

Anyway; adding this server fixed it, and it nicely showed the value of testing your failover clusters ahead of time.

Now we should have a super-cluster ready for SharePoint databases! See part 2 for how.]]> https://docs.microsoft.com/archive/blogs/sambetts/repairing-onedrive-next-gen-sign-in-loop-of-doom-on-windows-10 Thu, 29 Sep 2016 09:17:35 GMT https://blogs.msdn.microsoft.com/sambetts/?p=1445 So I had a long-running issue where the next-generation OneDrive sync client just wouldn’t sign-in to my corp account, and nothing was syncing.

I had tried the nice steps laid out on the support site, plus some more, but to no avail – the icon would stubbornly sit on “OneDrive for Business – Signing in” forever.

Adding the account again would result in a big red message saying “You’re already syncing this account”, and even removing the cached credentials had no effect.

Well; I fixed it in the end, so here’s how I did it & how I’d recommend you try too if you’re also struggling.

1. Look at the Official Support Guide

Make sure you look at what the product-group has written about troubleshooting OneDrive issues - https://support.office.com/en-us/article/Fix-OneDrive-sync-problems-83ab0d8a-8400-45b0-8dcf-dc8aa8a6bcf8?ui=en-US&rs=en-US&ad=US – make sure you’ve at least looked at the solutions there.

This blog-post is not gospel when it comes to what is officially supported; just my personal hacking that made OneDrive syncing finally work.

2. Try Removing the OneDrive Cached Credentials

I noticed some users had an issue where the credentials stored became corrupt. Delete them after killing the OneDrive process, then restart OneDrive.

OneDrive will of course need to re-authenticate to begin syncing, and maybe this alone will work. Not for me however…

3. Try a OneDrive Client Reset

Kill and reset the OneDrive process(es) by running this:

%localappdata%\Microsoft\OneDrive\OneDrive.exe /reset

That alone might even be enough to fix your problem; run it again to see if it gets any further. Disclaimer in case it’s not obvious: this will of course reset the local sync status of any file, so you’ll have to do a full-sync again.

Run OneDrive again to see if it worked of not. Again, for me this wasn’t enough; it would keep trying to sync anyway, and never signing in.

4. Uninstall the OneDrive Client and Reinstall

This is what worked for me in the end. All the Microsoft sites seem to suggest at least that OneDrive is a core component of Windows 10 at least, and it sort of is, but it’s one that can be removed & upgraded aside from standard Windows patches so it isn’t really core Windows.

Long story short: you can uninstall it and then install it again, which removes the configuration cache too.

Kill/reset the OneDrive processes with:

%localappdata%\Microsoft\OneDrive\OneDrive.exe /reset

Now uninstall with this:

%SystemRoot%\SysWOW64\OneDriveSetup.exe /uninstall

The uninstall is silent and pretty quick; don’t expect any confirmation it worked, just wait 20-30 seconds and it’s probably done.

Install again from the web (https://onedrive.live.com/); click the download button, despite being told there’s no need:

Once it’s installed, everything will have been factory-reset, which is what should clear the blockage.

Now configure OneDrive again like the 1^st time ever, and you should be able to sign-in again.

Finally, we have a syncing account! That said; I said to use the previous location so there’s one or two extra sync issues to solve, but at least it’s doing something now:

That’s it; I hope one of these solutions works for you too!

// Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/sharepoint-disaster-recovery-vs-active-passive-farms Thu, 14 Apr 2016 16:29:22 GMT https://blogs.msdn.microsoft.com/sambetts/?p=1295 Just a quick clarification on terminology & methodologies for SharePoint “disaster recovery” (DR).

In case you didn’t know already, multiple SharePoint farms can be run sharing the same content data, which is very handy if you need near 100% uptime for your SharePoint sites & apps. If for any reason your primary farm dies, you have another farm waiting for you. This post isn’t new in ideas; this is mainly just a quick note on terminology & why there are these differences really, as there is still some confusion.

This trick is achieved by sharing certain databases between two farms, with said databases being in read/write on the “primary” side. All the users are on the whichever farm has read/write access to the databases with the other side(s) receiving any data changes & running in read-only mode.

If for any reason we need to switch farms, we put the read-only DBs in read/write mode and send everyone to the other farm.

SharePoint fully supports having service-application & content-databases in read-only mode and can switch between the two modes without any intervention.

A Quick History – Secondary Farm for DR Only

Back in the day, before SQL Server databases could be kept in sync with either mirroring or log-shipping. At least in the case of SharePoint DR with log-shipping at least (which was the most common DR method), the problem was that switching-over the read/write SQL instances was a “one-hit” use. That’s to say you could easily switch from primary SQL instance to the secondary instance (in the event of the need arising), but going back again took a lot more work.

In the event of a failure on farm 1, we’d go from this:

…to this…

The only problem is that the switch back for SQL can take a while to get online & ready to failover again.

Anyway, because of this “one-way” failover nature, the secondary farm was strictly used for emergencies only, hence the concept of the farm being “only for disasters” and therefore the name “disaster recovery farm”.

Normally this was fine because it’s rare for multiple critical, farm-wide problems to happen on both sides. Not impossible, but rare, so this was still a good option to have available even if it was just for critical failures on the primary farm only.

Enter: Quick-Switching Failovers with AlwaysOn

These days with SQL Server AlwaysOn, SQL instances switching is very much easier than before. For one thing, when we switch primary SQL instances, switching back doesn’t require any extra work.

What does that mean? Well it means now we can switch between the two SQL instances much quicker than before.

What does that mean? Simple really; enter the concept of “active/passive” farms rather than the more dramatic “disaster recovery” farm model. With active/passive farms switching is much quicker; just a simple SQL failover + users redirect each time.

Now we can go from this:

…to this…

…and back again. And back again; no restores or DB tricks needed except a failover.

What’s the Correct Name & DR Model Then?

Good question; a lot depends on your original plans for the 2^nd farm. In general, the old-style “only in disasters” model is a bit rubbish as it relies on having a disaster to know whether everything will even work, as it is the “nuclear option” for disasters. I’ve seen cases where everything “worked” on the DR site but when push-came-to-shove, the hardware just wasn’t ready for the same load; and of course, this only became apparent when the primary went nuclear so everyone was moved over to the DR site.

Partly to avoid unpleasant surprises, my recommendation is we forget about “nuclear option DR farms” and just get used to having two equally active SharePoint farms (as in both switching between active/passive). Now we have an easy way of failing over there doesn’t seem like much reason not to, and it guarantees that both could work in the event of an emergency.

Remind me Again – What Could Force a Failover?

Patching & updates mainly; it’s a necessary but risky business, on any platform.

Patching Windows, SQL Server(s), SharePoint installations; all of these have risks in that there’s always a chance whatever update will break services. From Windows platform to .net to SharePoint; despite our best efforts, servers are complicated beasts so very occasionally something may slip through the cracks.

This isn’t something specifically tied to Microsoft patches either; I challenge someone to find a vendor that doesn’t have occasional patching fracases. Hint: there aren’t any.

The solution to this is simple: test patches first, and have another production system on stand-by in case something critical dies.

Have no single points of failure in other words, and active/passive farms are the ultimate high-availability SharePoint solution because they’re the only architectures that achieve this.

Patching isn’t the only reason; your own code may cause issues, and it’s nice to have quick failback options. I can think of more than more big SharePoint customer that’s benefited greatly by having this capability for handling bad code rollouts.

There’s all sorts of reasons why it’s worth doubling-up on farms, but mostly it’s for the reasons you can’t think of you’ll need it the most ;)

Cheers,

Sam Betts]]> https://docs.microsoft.com/archive/blogs/sambetts/sharepoint-upgrade-configuration-wizard-never-finishes Fri, 01 Apr 2016 13:27:32 GMT https://blogs.msdn.microsoft.com/sambetts/?p=1193 Closing programs via task manager will send it WM_CLOSE, and then drop the process by force if it doesn’t respond within a few seconds. Well, the process hasn’t crashed so the program will exit “cleanly” at least. Now we just have to finish the upgrade from the command-line. Open a SharePoint PowerShell command-line & run:

PSCONFIG.EXE -cmd upgrade -inplace b2b -wait

How to patch with no downtime with SQL Server AlwaysOn has been covered already, but not with service-applications in sync too. This is a complex subject so be prepared!

It helps greatly if content & service-applications are in different SQL Server Availability Groups, but that’s not always how the back-end is setup; quite often all SharePoint databases are on the same one. This post outlines the process for both cases.

Some key terms here:

• Primary farm = “farm1”.
• Secondary farm = “farm2”.
• SQL Server AlwaysOn Availability Group = “AG”.
• PSConfig = this command-line tool preferably, or the SharePoint Configuration Wizard.

Note: you can do this either way round; swap farm1 for farm2 if you like, and the processes are the same, just in reverse.

The Synchronised Farm Upgrade Challenge

First though, a bit about the challenge we’re up against. It’s quite epic if I don’t say so myself…

In short, we have two distinct farms that share databases in active/passive mode. We need to upgrade both farms without users suffering any downtime.

With a setup whereby service application databases are synchronised between two separate farms, you have an issue where you’ll need to upgrade the service application databases at some point – how to do so while also keeping them operational 100% of the time?

PSConfig will obviously have issues if it has to upgrade a read-only service-application database, so we can’t just run this on the inactive farm without some tricks & workarounds to side-step these roadblocks.

Finally, given we want to try and keep users in read/write mode in all SharePoint sites, the challenge becomes harder still. How to let users continue working normally but also locking databases for upgrades, especially given they’re synchronised between two (temporarily) disjointed SharePoint versions?

Synced Farm Upgrade Strategies

There’s a few strategies to attack this “how to upgrade synced farms” challenge:

1. All SharePoint functionality kept in read-only mode until both farms are fully upgraded.
2. Users have read/write access while upgrade is going on.

The first strategy is the easiest, but rarely acceptable for the business needs – users need to update, and if they can’t it shouldn’t be for long. SharePoint patching can potentially be a long process!

The second strategy is more commonplace, but with a couple of different approaches to getting there.

Upgrading with Read/Write Functionality

Two approaches to patching SharePoint while users can still edit content:

1. Disconnect service-applications from 1^st upgraded farm so we can keep all SharePoint databases in read-only mode during PSConfig.
2. Upgrade the service-app databases on 1^st farm to be upgraded; overwrite the 2^nd farms’ databases once all farms are fully upgraded.

The first approach basically involves upgrading each farm without anything attached & mounting the service-apps again with the yet-to-be-upgraded databases:

• Users & SharePoint databases active on farm1
  • Remove all synced service-apps & content DBs from farm2.
  • Upgrade farm2
  • Add all synced service-apps & content DBs to farm2 again.
• Switch users & databases to farm2
  • Remove all synced service-apps & content DBs from farm1.
  • Upgrade farm1
  • Add all synced service-apps & content DBs to farm1 again.
• Now finish farm upgrade with SPDatabase.Upgrade on everything previously disconnecte.

I don't think this is the best way so I’m focusing on the last option because it doesn’t involve recreating service-applications, which can be quite a big task admin task potentially. Also, it is (in my opinion) safer as there's more chance to react & rollback should you have any upgrade problems, even if both methods are valid.

How to Upgrade Synchronised Farms Without Deleting Service-Applications

As if it wasn't complicated enough already, how then to upgrade via my preferred approach also depends on if you’ve put all your SharePoint databases in a single SQL Server Availability Group or not (probably you have)…

All Databases in One Availability Group (AG)

This is the most common setup, but the most complex to update. For this configuration, we’ll patch the farm2 service-application DBs while users are still on farm1 (in full read/write mode for content databases). That does means we have to make sure farm1 doesn’t allow updates to (only) service-applications while we upgrade the same service-apps on farm2. This is easily done by making the service-apps read-only on farm1 during farm2s’ upgrade.

Short version:

1. Patch farm2 while users & DBs stay on farm1.
   • Install binaries.
   • Dismount content DBs on farm2.
   • Disconnect service-app DBs from availability group.
     • Make databases on farm1 read-only.
     • Allow read/write for databases on farm2.
   • Finish upgrade on farm2 with PSConfig - upgrade service-applications too.
   • Mount content-databases to farm2.
   • Switch users and databases to farm2.
2. Patch farm1 while users on farm2
   • Install binaries.
   • Dismount content DBs
   • Drop read-only service-app databases on farm1 SQL instance.
   • Add service-app DBs from farm2 SQL instance back to availability group.
   • Finish upgrade on farm1 with PSConfig now farm1 has already-upgraded service-app DBs.
3. Upgrade content databases in PowerShell. All done!

We need to make service-app DBs read-only on the active farm (farm1) because farm2 service-app databases will ultimately overwrite them, so any data we change on farm1 in any service-app during upgrade would be lost. Users can still edit content while farm2 is being patched, just not taxonomies, user profiles, etc. Small note: this doesn’t include search btw; that’s a whole different game.

So far so good. But the complication is that farm1 has read/write access to the AG while we patch farm2 so our beloved users can still keep working in normal read/write mode for their content & sites. Of course though farm1 having full read/write access to the synced databases means therefore farm2 only has read-only access to everything in the AG, which will break the PSConfig stage of the upgrade if we don’t workaround this.

Patch farm2 while users use farm1

So in this example, our users keep using the normal primary site & we’re patching the secondary (farm2) in preparation.

1. Install patch binaries on farm2; all servers at once. You may need to reboot afterwards.

In the meantime, we have farm1 to handle traffic and farm2 will have read-only access to everything not configuration.

1. Farm2 now has latest binaries; now needs to run PSConfig to update databases and other stuff.

• Dismount content-DBs from farm2 to avoid PSConfig errors.

Next-up, how to deal with service-app upgrades.

Upgrade Service-Applications on Farm2

As mentioned above, we now have the issue that read-only service app DBs aren’t upgradable in PSConfig, which is a problem as we’re currently upgrading a farm with everything in read-only.

We’re going to deal with this by actually upgrading our service-apps now. That’s a bit awkward given we can’t do so easily as we’re in one AG for all databases, so time to remove the service-app databases from the AG sow farm2 can upgrade them.

• Remove service-apps from the availability group.
  • Run this for each service-app database on the primary SQL AlwaysOn instance (change the database name as necessary):

ALTER AVAILABILITY GROUP [SP2013]

REMOVE DATABASE [App_Management];

GO

• The database in question will no long be replicating between SQL instances as it's no long in the AG, with the secondary SQL instance having the database in a “restoring” state.

• Set farm1 databases as read-only & enable read/write for farm2 databases. Run on the primary SQL node:

ALTER DATABASE [App_Management] SET READ_ONLY WITH ROLLBACK IMMEDIATE

GO

• The database on the primary AlwaysOn SQL instance will now be read-only.
  • Later, we’re going to overwrite the primary instance with the upgraded secondary instance one it’s upgraded & we’re ready.
• Now we need to restore normal operation to the database on the secondary SQL instance so we can read & write to it. Run this on the secondary SQL node:

RESTORE DATABASE [App_Management]

GO

Make sure you repeat this process for all service-app DBs.

Now farm2 should have full read/write access to the service-application DBs & farm1 with read-only access to the same databases. Farm1 still has full read/write access to content databases.

This is how your farm1 SQL instance should look like. Nobody can edit these service-apps, which is good for the time-being. Content databases are in read/write mode at least, so unlikely to be a big deal.

• Run PSConfig on farm2 to finish upgrade, upgrading the now R/W service-apps too.

• Attach content DB to upgraded secondary farm (content DB still un-upgraded).

Congratulations, farm2 is all upgraded (minus the content DB).

Patch Farm1 site while users use Farm2

With one down, there’s one to go. This is a bit simpler.

• Failover users + content databases to upgraded farm2.
  • Users now have full read/write (upgraded) service-apps as well as read/write content-databases too.
• Detach content-database from farm1.
• Install binaries on farm1 now nobody’s using it.

Once everything’s been installed & rebooted (if necessary), we need to run PSConfig. But this time we don’t need to upgrade the service-app databases as we did that already, so…

• Drop all read-only service-app databases on farm1 SQL instance.

DROP DATABASE [App_Management]

GO

• On farm2 SQL instance, add service-application databases back into availability group.

When this completes, farm 1 will also have the upgraded service-application databases, and they’ll be back in sync again.

• Run PSConfig to finish upgrade.
  • Here’s the clever bit: it won’t need to upgrade the service-application databases as they’ve already been upgraded (copies from farm2).

Congratulations! Farm1 is now also upgraded. Finish off the process with:

• Upgrade content-database with Upgrade-SPContentDatabase.

Content & Service-Apps in Different AGs

If you have your service-app DBs & content DBs in separate Availability Groups, then well done you for forward-thinking - it'll now pay off. This is the better setup as it gives greater failover dexterity – one SharePoint farm can have service-applications in read-only but content in full-read/write at the same time. Each group fails-over independently; very handy for patching & upgrading SharePoint databases!

Short version:

1. Patch farm2 while users & DBs stay on farm1.
   • Install binaries.
   • Dismount content DBs on farm2.
   • Failover “service-apps” AG to farm2 SQL instance.
     • No hacks needed here; it’ll just work.
   • Suspend data movement for all service-app DBs.
     • You’ll break farm1 if it receives the patched databases without having the equivalent binaries installed, which right now it doesn’t have.
   • Finish upgrade on farm2 with PSConfig. Service-apps upgraded because they’re read/write
   • Mount content-databases to farm2.
   • Switch users and content-databases to farm2.
2. Patch farm1 while users on farm2
   • Install binaries.
   • Dismount content DBs
   • Resume data movement in service-app AG so farm1 gets patch changes for service-app DBs.
   • Finish upgrade on farm1 with PSConfig.
3. Upgrade content database in PowerShell.

Ah, so much cleaner!

Wrap-Up

That’s it for now. If anything’s not clear, let me know in the comments below – it’s a complex subject so it’s possible.

Cheers,

Sam Betts