SharePoint Server Sync, Permission, and Access Errors, All Fixes
Why This Is Happening
You just stood up a brand-new SharePoint Server farm, ran the Products Configuration Wizard, and the first thing you see in Central Administration is a bright orange "Upgrade Available" banner. Or maybe SharePoint Server is throwing a cryptic 800703fa Illegal operation attempted on a registry key that has been marked for deletion error buried in your ULS logs, and users are calling you because their MySite feeds won't load. I've seen both of these on dozens of production farms, and I know exactly how disorienting it feels when a fresh install immediately looks broken.
Here's the reality: neither of these errors means your SharePoint environment is fundamentally broken. They're symptoms of a small but important mismatch between what the Configuration Wizard set up and what the farm's databases actually expect.
For the SharePoint Server 2016 "Upgrade Available" status, the root cause is straightforward, some components inside the SharePoint_AdminContent_<GUID> database weren't stamped to the expected version when the Configuration Wizard created the Central Administration AdminContent database. The wizard does a lot in one pass, and occasionally certain upgrade sequences, particularly ones tied to Project Server extensions (specifically Microsoft.Office.Project.Server.Database.Extension.Upgrade.PDEUpgradeSequence), don't get finalized. The result is that the farm's status column reads "Upgrade Available" and the database shows as "Database is in compatibility range and upgrade is recommended", even though you just installed everything from scratch. Running Get-SPFarm | Get-SPPendingUpgradeActions -recursive will usually confirm this, listing pending upgrade actions against the AdminContent database.
For the 800703fa COM exception affecting SharePoint Server 2013 and 2010, the story is different. This error appears when a COM class factory tries to instantiate, typically SPRequest, and hits a Windows registry key that's been flagged for deletion. In practice, this almost always traces back to a worker process (w3wp.exe) that is still running while a registry cleanup or an IIS reset is mid-flight. The error cascades through Microfeed operations, Taxonomy service calls, and user token resolution. Users see stalled social feeds, broken term store connections, or access failures that seem random.
What makes both of these errors genuinely frustrating is that Microsoft's default error messages give you almost nothing to work with. "Upgrade Available" on a fresh install? That's backwards. And "Illegal operation attempted on a registry key", what registry key? Where? The ULS logs give you the full stack trace if you know where to look, but most administrators don't have time to dig through gigabytes of SharePoint log entries.
The good news: both problems have clean, well-documented resolutions. You don't need to rebuild your farm. You don't need to open a support ticket. You just need the right PowerShell commands and a clear sequence of steps, which is exactly what this guide covers. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your SharePoint Server 2016 Central Administration is showing "Upgrade Available" on a new farm, and you just want this gone as fast as possible, here's the single fastest fix. Open the SharePoint 2016 Management Shell as an Administrator, don't use a regular PowerShell window, it won't have the right snap-ins loaded, and run this one command:
Get-SPWebApplication <Central Administration URL> | Get-SPContentDatabase | Upgrade-SPContentDatabaseReplace <Central Administration URL> with your actual Central Administration URL, which typically looks something like http://servername:<port>. You can find this URL by going to SharePoint Central Administration → System Settings → Manage Servers in this Farm and noting the Central Administration URL listed at the top of the page.
Run the command, wait for it to finish (it usually takes 2–5 minutes on a fresh farm), and then refresh your Central Administration page. In most cases, the "Upgrade Available" status disappears immediately. The database status for SharePoint_AdminContent_<GUID> will shift from "upgrade recommended" to a clean healthy state.
For the 800703fa registry key error, the fastest mitigation is an IIS reset followed by an application pool recycle. Open an elevated Command Prompt and run:
iisreset /noforceThen go to IIS Manager → Application Pools, right-click each SharePoint-related app pool, and choose Recycle. This clears the stale COM references that are causing the registry key collision. It won't permanently fix the underlying cause if you have a recurring pattern, but it stops the immediate bleeding and gets users back online.
Get-SPFarm | Get-SPPendingUpgradeActions -recursive in the SharePoint Management Shell first. This gives you a full list of pending upgrade actions with object names, types, and status, so you know the scope before you start, and you can verify the list is empty after the fix completes.
This step sounds trivial but it's where a lot of fixes fall apart. The SharePoint 2016 Management Shell must be opened by an account that is both a local Administrator on the server and a SharePoint Farm Administrator. Running it as the wrong account produces misleading "access denied" errors that have nothing to do with the actual problem you're solving.
On the SharePoint Server, click Start, expand the Microsoft SharePoint 2016 Products folder, right-click SharePoint 2016 Management Shell, and select Run as administrator. Don't just double-click it, you need the elevated session. When the UAC prompt appears, confirm it.
Once the shell opens, verify you're in the right context by running:
Get-SPFarm | Select-Object Name, BuildVersion, StatusYou should see your farm name and a build version. If this command returns an error about being unable to connect to the configuration database, you're either using the wrong account or the SharePoint services aren't fully running. Check Services.msc and make sure SharePoint Timer Service and SharePoint Administration are both in a Running state before proceeding.
If everything looks good here, farm name returns, build version shows, you're ready for the next step. The Management Shell is your command center for SharePoint Server upgrade operations and it needs to be in a healthy state before any fix will work reliably.
Before you touch anything, get a complete picture of what's actually affected. Run this command in your elevated SharePoint Management Shell session:
Get-SPFarm | Get-SPPendingUpgradeActions -recursiveGive it a minute, this command interrogates every object in the farm hierarchy and it can be slow on larger environments. What you're looking for in the output are entries with a Status of NeedsUpgradeBackwardsCompatible or NeedsUpgrade, along with the ObjectName field telling you which database or component is affected.
On a freshly created SharePoint Server 2016 farm, you'll typically see output like this for the AdminContent database:
ObjectName : SharePoint_AdminContent_<GUID>
ObjectType : Microsoft.SharePoint.Administration.SPContentDatabase
ParentName : SharePoint Central Administration v4
Status : NeedsUpgradeBackwardsCompatibleThe presence of Microsoft.Office.Project.Server.Database.Extension.Upgrade.PDEUpgradeSequence in the UpgradeActions list is a key tell, it means the Project Server database extension upgrade sequence wasn't completed. This is the documented root cause for the "Upgrade Available" status on new farms.
Take a screenshot or copy the output to a text file. You want a baseline of what was broken so you can confirm it's fully gone after the fix. Also check the Central Administration UI, navigate to Upgrade and Migration → Review Database Status, and make a note of which databases show "Database is in compatibility range and upgrade is recommended."
Now you're ready to actually fix the SharePoint Server "Upgrade Available" status. In your elevated Management Shell, run the following command, substituting your actual Central Administration URL:
Get-SPWebApplication http://<servername>:<port> | Get-SPContentDatabase | Upgrade-SPContentDatabaseThis pipes your Central Administration web application through Get-SPContentDatabase to retrieve the SharePoint_AdminContent_<GUID> database, then passes it to Upgrade-SPContentDatabase which runs the pending upgrade sequences that the Configuration Wizard left incomplete.
You'll see progress output in the shell as it works through the upgrade actions. Depending on how many pending items there are, this takes anywhere from 90 seconds to about 10 minutes. Don't close the shell window while it's running, let it finish completely. If it exits cleanly without errors, that's your green light.
After the command completes, verify the fix worked by running the pending upgrade check again:
Get-SPFarm | Get-SPPendingUpgradeActions -recursiveThis time, the output should be empty or show no entries related to the AdminContent database. Then check stsadm -o LocalUpgradeStatus, instead of "Needs Upgrade," you should now see clean status for the affected database. Finally, refresh Central Administration. The "Upgrade Available" banner in the Manage Servers view should be gone.
If your SharePoint Server environment, particularly on SharePoint 2013 or 2010, is throwing COMException (0x800703FA) errors in ULS logs, the approach is different. This error appears when the w3wp.exe worker process tries to instantiate a COM component via SPRequest..ctor() and hits a Windows registry key that's been flagged for deletion at the OS level.
Start by confirming the error in your ULS logs. Open SharePoint LogViewer (or use Merge-SPLogFile in the Management Shell) and search for 0x800703FA or 800703fa. The entries will typically reference CLSID {BDEADF26-C265-11D0-BCED-00A0C90AB50F} and a call stack running through Microsoft.SharePoint.Library.SPRequest.
Once confirmed, the fix involves a controlled recycle of the IIS worker processes. Run this from an elevated Command Prompt:
iisreset /noforce
net stop SPTimerV4
net start SPTimerV4The /noforce flag tells IIS to wait for existing requests to complete before resetting, this is important in production environments where you don't want to abruptly drop active user sessions. Restarting the SharePoint Timer Service clears any cached state that may be holding stale registry references.
After the reset, monitor your ULS logs for 15–20 minutes. If the 800703fa entries stop appearing, the recycled worker processes have re-initialized cleanly against valid registry keys. If the error persists or returns after a few hours, you're dealing with a recurring trigger, move on to the Advanced Troubleshooting section below.
If the PowerShell Upgrade-SPContentDatabase command resolved the issue for most databases but you're still seeing "Upgrade Available" in Central Administration, or if the Management Shell approach didn't work for you, the fallback is to run the SharePoint 2016 Products Configuration Wizard from the command line using PSConfig.exe. This is a more thorough approach that reinstalls features, application content, and secure resources in a single pass.
Open an elevated Command Prompt (not PowerShell, cmd.exe works better for PSConfig) and run:
PSConfig.exe -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures -cmd secureresourcesLet's break down what each flag does, because this command is doing a lot of work. The -cmd upgrade -inplace b2b -wait -force section runs the farm upgrade synchronously and forces it to completion even if there are warnings. The -cmd applicationcontent -install portion re-deploys application content like Central Administration resources. The -cmd installfeatures re-registers all SharePoint features. And -cmd secureresources re-applies ACLs to SharePoint resources on disk.
This command will take longer than the PowerShell approach, expect 10–20 minutes on most servers. You'll see progress output in the Command Prompt window. When it finishes, log back into Central Administration. Check Manage Servers in this Farm, the Status column should now show a healthy state with no "Upgrade Available" indicator. Then run Get-SPFarm | Get-SPPendingUpgradeActions -recursive one final time to confirm the pending actions list is clean.
Advanced Troubleshooting
Most SharePoint Server upgrade and registry errors resolve with the steps above. But some environments have complicating factors, domain policies, locked-down registry permissions, custom solutions deployed against the farm, or third-party antivirus software interfering with IIS worker processes. Here's how to dig deeper when the standard fixes don't stick.
Reading ULS Logs for the Full Call Stack
When the 800703fa COM exception keeps returning, your best diagnostic tool is the ULS log. Open the SharePoint LogViewer or navigate to the ULS log directory (default: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\ for SharePoint 2016, ...\15\LOGS\ for 2013). Sort by timestamp and look for clusters of 0x800703FA entries. Note the exact time, the w3wp process ID, and the correlation ID. Then grep for that correlation ID across all log files to see the full chain of events leading to the error.
Pay particular attention to whether the errors correlate with scheduled IIS application pool recycling times. Many administrators find that the 800703fa error appears reliably at 2:00 AM or another scheduled recycle time, because the default IIS recycle schedule spins down the old worker process while a SharePoint background job is mid-execution. Changing the IIS application pool recycle schedule to a known-quiet window (3:00–4:00 AM, for example) can eliminate the recurring trigger entirely.
Checking SharePoint Timer Service Job Schedules
In Central Administration, go to Monitoring → Review Job Definitions. Look for any timer jobs that are scheduled to run at the same time your 800703fa errors appear. Social feed jobs, user profile sync jobs, and taxonomy refresh jobs are common culprits. If a timer job is firing during an IIS recycle, the COM instantiation fails because the registry keys used by the retiring worker process are being cleaned up by Windows while the timer job still needs them. Staggering the schedules, moving social feed repopulation jobs to run 30 minutes before or after the IIS recycle, often eliminates the problem without any code changes.
Verifying Farm Account Registry Permissions
If you're seeing 800703fa errors specifically tied to the SPRequest constructor across multiple SharePoint Server machines in your farm, check whether the farm service account has adequate registry permissions on all nodes. Open regedit on the affected server, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0 (for SharePoint 2016), right-click, select Permissions, and verify the farm service account has at least Read access. Missing or corrupted registry ACLs after a server patch cycle can cause intermittent registry access failures that manifest exactly as 800703fa errors.
Enterprise and Domain-Joined Scenarios
In domain environments with Group Policy Object restrictions, you may find that GPOs are periodically resetting registry permissions or blocking COM class factory access. Work with your Active Directory team to check the GPO Event Log on the SharePoint server, specifically Event IDs 1085 and 1125 in the System log, to see if policy application is coinciding with your error windows. If so, you may need to add a GPO exception for the SharePoint farm service account or coordinate with your domain admins on the policy scope.
Upgrade-SPContentDatabase command and the full PSConfig.exe command-line wizard, and the "Upgrade Available" status or 800703fa errors persist across multiple server reboots, it's time to engage Microsoft Support directly. Collect your ULS logs (at least 48 hours worth), the output of Get-SPFarm | Get-SPPendingUpgradeActions -recursive, and your farm build version before you call, this dramatically shortens the time Microsoft's support engineers need to diagnose your specific environment.
Prevention & Best Practices
Once you've resolved the immediate SharePoint Server upgrade or registry errors, the goal is to make sure you're not back here in six months dealing with the same thing. Most of these problems are predictable and preventable with a few consistent habits.
The single most impactful thing you can do is always run the Configuration Wizard from the command line after any SharePoint Server patch or cumulative update installation, even when the GUI wizard appears to complete successfully. The PSConfig.exe command gives you explicit control over each phase of the upgrade and, critically, exits with a non-zero error code if something fails. The GUI wizard sometimes swallows errors silently, which is exactly how you end up with a "Upgrade Available" status on what should be a clean farm.
Set a calendar reminder to check Get-SPFarm | Get-SPPendingUpgradeActions -recursive one week after every patch cycle. This command takes less than two minutes to run and catches pending upgrade actions before they turn into visible errors in Central Administration or user-facing access problems. Make it part of your patch validation checklist, not an afterthought.
For environments affected by the 800703fa registry error, stagger your maintenance windows. Don't schedule IIS application pool recycling, SharePoint Timer Service restarts, and Windows Update reboots to happen within the same 30-minute window. These operations all interact with the Windows registry and COM subsystem, and running them simultaneously dramatically increases the chance of a worker process hitting a registry key that's mid-cleanup.
Monitor your ULS logs proactively. You don't need to read every line, but setting up a simple PowerShell script that counts 800703FA occurrences in each day's logs and emails you when the count exceeds a threshold gives you early warning before users start reporting broken features. Most production SharePoint environments should have zero of these errors in normal operation. Even two or three per day is a signal worth investigating.
- Always apply SharePoint Server cumulative updates one at a time, running PSConfig.exe after each one, never stack multiple updates before running the wizard.
- Create a pre-upgrade snapshot or VM checkpoint before any Configuration Wizard run, rollback is fast, rebuilding isn't.
- Keep the SharePoint farm service account's password synchronized across all services, stale credentials cause COM instantiation failures that look identical to registry errors.
- After every IIS reset or app pool recycle in production, confirm ULS logs show clean startup entries before marking the maintenance window closed.
Frequently Asked Questions
Why does SharePoint Server 2016 show "Upgrade Available" right after a fresh install?
This happens because the SharePoint 2016 Products Configuration Wizard doesn't always complete every database component upgrade in the SharePoint_AdminContent_<GUID> database, specifically sequences tied to Project Server database extensions. It's not a sign of a broken farm; it's an incomplete stamp on the database version. Running Get-SPWebApplication <CA URL> | Get-SPContentDatabase | Upgrade-SPContentDatabase in the SharePoint Management Shell resolves it cleanly by finishing what the wizard started. After that command completes, your "Upgrade Available" status disappears and the AdminContent database reports a healthy state.
What does the 800703fa error actually mean in SharePoint, and is it dangerous?
The 800703fa HRESULT error code means "Illegal operation attempted on a registry key that has been marked for deletion" at the Windows level. In SharePoint Server 2013 and 2010 environments, it surfaces when a COM class factory, typically the SPRequest object that SharePoint uses extensively for HTTP requests, tries to load while Windows is in the process of cleaning up registry keys associated with a terminating process. It's not dangerous in the sense that it won't corrupt your data, but it does cause request failures for affected users, particularly in Microfeed, Taxonomy, and user profile operations. Recurring occurrences that aren't tied to a specific maintenance event warrant investigation.
Can I run Upgrade-SPContentDatabase without taking the farm offline?
Yes, for the AdminContent database on a fresh farm showing "Upgrade Available," you can run Upgrade-SPContentDatabase without taking anything offline. The upgrade affects the Central Administration content database, not user content databases, so regular users won't experience any disruption. Central Administration itself may respond slightly slowly during the upgrade command, but it stays online. For user-facing content databases on larger production farms, some administrators choose to schedule the command during a low-traffic window out of caution, even though the upgrade process is designed to run without requiring downtime.
What's the difference between running PSConfig.exe and using Upgrade-SPContentDatabase?
Upgrade-SPContentDatabase targets a specific database and runs its pending upgrade sequences, it's surgical and fast, usually the right first choice for the "Upgrade Available" status on a new SharePoint Server farm. PSConfig.exe with the full upgrade flags is a broader operation that reinstalls features, application content, and resource permissions across the entire farm configuration, it does more, takes longer, but is more thorough when you're dealing with multiple affected components or when the PowerShell command alone didn't fully clear the issue. Think of Upgrade-SPContentDatabase as a targeted fix and PSConfig.exe as the full reset.
How do I find the Central Administration URL to use in the upgrade command?
The easiest way is to open Central Administration in your browser, the URL in the address bar is exactly what you need for the Get-SPWebApplication command. It usually looks like http://<servername>:<port> with a non-standard port number (often in the 10000–50000 range). Alternatively, run Get-SPWebApplication | Where-Object {$_.IsAdministrationWebApplication} in the SharePoint Management Shell, this returns the Central Administration web application object directly, including its URL, so you know exactly what to substitute into the upgrade command without any guesswork.
My SharePoint Server farm has multiple servers, do I need to run these commands on each one?
For the Upgrade-SPContentDatabase command, you only need to run it once from any single SharePoint Server in the farm that has the Management Shell. Database upgrades run against the SQL Server database itself, not against individual web front-ends, so running it from one machine is sufficient. For the PSConfig.exe command, however, you do need to run it on every server in the farm, configuration changes applied via PSConfig need to be applied to each server's local SharePoint binaries and registry settings. Microsoft recommends running PSConfig.exe on the central administration server first, then on each additional server in the farm one at a time.