Install SharePoint Server Prerequisites Offline from a Network Share

An offline SharePoint Server installation fails long before the farm exists if the prerequisite packages, Windows feature source and restart plan are wrong.

The safe approach is not to download an old “all prerequisites” ZIP from a blog. Build a manifest for the exact SharePoint edition and Windows Server build, download every package from Microsoft on a connected staging machine, verify and transfer it through your security process, then run Microsoft's PrerequisiteInstaller.exe against the controlled local source.

This article focuses on SharePoint Server Subscription Edition (SE) and shows how to keep the method repeatable without inventing packages that SharePoint does not require.

The short answer

Microsoft supports installing SharePoint Server prerequisites from an offline folder or network share.

For Subscription Edition, the maintained software-requirements page currently identifies the core prerequisite set as:

• the Web Server (IIS) role and required Windows features;
• Microsoft .NET Framework 4.8;
• the applicable Visual C++ Redistributable.

The same page documents these useful installer switches:

• /WindowsSource:<path> — use local Windows Features on Demand files;
• /DotNet48:<file> — use a local .NET Framework 4.8 installer;
• /MSVCRT142:<file> — use the documented Visual C++ prerequisite file;
• /unattended — run without interactive prompts;
• /continue — continue after a restart.

Do not add .NET 8, PowerShell 7, Exchange Unified Messaging packages or random SQL/TLS components to that list because another workload uses them. They are not documented SharePoint Server SE prerequisites.

First: freeze the exact build target

Record all of this before downloading anything:

• SharePoint Server edition: Subscription Edition, 2019, 2016 or an older supported build;
• SharePoint product media/build;
• Windows Server edition, version and installation option;
• SQL Server version and location;
• language packs;
• required SharePoint feature update and cumulative/security update baseline;
• whether the server has any route to Windows Update;
• where installation logs and evidence will be retained.

Do not use the Subscription Edition package list for SharePoint 2019 or 2016. Microsoft's network-share installation article applies to several SharePoint versions, but the required switches and files differ by product.

For SE, confirm the operating system against Microsoft's current SharePoint Server Subscription Edition system requirements. Windows Server support is a product compatibility question, not a guess based on whether Setup happens to start.

Build a prerequisite manifest

Create a small manifest rather than a folder of unexplained executables.

Use columns such as:

Field	Example purpose
Component	Human-readable package or Windows source name
Applies to	Exact SharePoint edition/build
Microsoft source URL	The page or download link used
File name	The staged file name
Version	File/product version after download
Size	Expected byte size
SHA-256	Hash calculated after download and after transfer
Signature	Microsoft signature verification result
Downloaded UTC	When the file was acquired
Approved by	Security/change owner
Offline path	Final controlled location

The manifest answers the question that appears six months later: what exactly did we install on these farm servers?

Subscription Edition warning: Visual C++ changed

Microsoft's current SE requirements page says Version 23H1 and later require the Visual C++ 2015–2022 Redistributable (x64), replacing the older 2015–2019 package. It also explains that this newer prerequisite is installed by the 23H1 feature update if missing, rather than by PrerequisiteInstaller.exe itself.

That is why a static blog download list ages badly. Use the maintained Microsoft page for your build and stage the applicable feature update and redistributable through the same controlled process.

Prepare the Windows feature source

Some required Windows roles and Features on Demand normally obtain payload files from Windows Update.

For an offline server, mount or copy the matching Windows Server installation media and make its sources\sxs folder available. The source must match the installed Windows Server version and language.

Example local path:

D:\sources\sxs

Example network path:

\\deployment01\software\windows-server\sources\sxs

Do not point several server versions at one convenient sxs folder. A mismatch produces missing-source and feature-install failures that look like SharePoint problems but are really Windows servicing problems.

Microsoft publishes the maintained PowerShell feature command for Subscription Edition. If you configure features manually, use that current command for the target build and add -Source <matching-sxs-path> when the server cannot reach Windows Update.

Download and verify on the staging machine

Use an internet-connected machine approved for software acquisition.

For every package:

1. start from the applicable Microsoft requirements page;
2. follow the Microsoft download link;
3. record the final file name, version and size;
4. verify the digital signature;
5. calculate a SHA-256 hash;
6. scan it using your organisation's approved controls;
7. add it to the manifest;
8. transfer it through the approved boundary process;
9. calculate the hash again after transfer.

Example PowerShell hash command:

Get-FileHash -Algorithm SHA256 -Path 'E:\staging\ndp48-x86-x64-allos-enu.exe'

The output proves that the transferred bytes match the staged bytes. It does not prove that the package is approved for your exact SharePoint build; that evidence comes from the Microsoft source and your build manifest.

Do not paste hashes from this article into your change record. Calculate them from the actual files you downloaded.

Lay out the offline source

Use a versioned, read-only share or a local folder copied from controlled media.

For example:

\\deployment01\software\sharepoint-se\
├── manifest.csv
├── product-media\
├── prerequisites\
├── updates\
├── language-packs\
├── windows-source\sources\sxs\
└── evidence\

Keep updates separate from prerequisites. A SharePoint cumulative update is not another argument to add casually to the prerequisite installer.

Grant farm servers read access to the source. Restrict write access to the small group that manages the approved software set.

Before the change window, sign in using the installation identity on each target server and confirm it can read every required file. Testing from your administrator workstation proves nothing about the farm server's access.

Run PrerequisiteInstaller.exe with local sources

Copy or mount the SharePoint product media on the server. Open Command Prompt or PowerShell as administrator, then change to the directory containing PrerequisiteInstaller.exe.

For a current Subscription Edition build, the command shape is:

.\PrerequisiteInstaller.exe `
  /unattended `
  /WindowsSource:"\\deployment01\software\sharepoint-se\windows-source\sources\sxs" `
  /DotNet48:"\\deployment01\software\sharepoint-se\prerequisites\<dotnet-4.8-installer>.exe" `
  /MSVCRT142:"\\deployment01\software\sharepoint-se\prerequisites\<documented-vc-installer>.exe"

Replace the placeholders with the exact files recorded in your manifest. Do not run the example literally.

Microsoft warns that when a local file/path option is omitted, the installer can try to download the prerequisite from the internet. An offline build therefore needs every applicable source argument present and readable.

For older SharePoint versions with more prerequisite packages, Microsoft's network-share procedure documents the version-specific switch/path pattern. Do not copy an old /Sync, /AppFabric or SQL Native Client switch into an SE command unless the requirements for your actual edition call for it.

Use an arguments file for repeated builds

Microsoft also supports an arguments text file. This helps keep several farm servers consistent.

The file contains the applicable switch and local path pairs. Keep the entire set on one line, as the Microsoft procedure requires for the affected versions, and store the file beside the manifest.

Then run the product's documented arguments-file command. Before automation, execute it on one disposable or pilot server and retain the log and exit code.

An arguments file is not a magic package detector. It still needs:

• correct switches for the SharePoint edition;
• files at every referenced path;
• a matching Windows feature source;
• an elevated session;
• a planned restart route.

Handle restarts deliberately

The prerequisite installer can stop for a restart.

Microsoft documents these relevant exit codes:

• 0 — success;
• 1 — another instance is running;
• 2 — invalid command-line parameter;
• 1001 — a pending restart blocks installation;
• 3010 — a restart is required.

After a required restart, sign back in and continue with:

.\PrerequisiteInstaller.exe /continue

Reapply the local-source arguments if required by your tested runbook. Do not let a generic automation wrapper treat 3010 as a clean, finished installation and proceed immediately to SharePoint Setup.

Before starting, check whether Windows already has a pending restart from servicing or another installation. A clean reboot before the change can remove one avoidable ambiguity, subject to your change process.

Read the logs

Subscription Edition writes prerequisite logs under:

%TEMP%\prerequisiteinstaller.<date>.<time>.log

Copy the log into the build evidence folder before another operator or cleanup job removes it.

When a component fails, record:

• the exact exit code;
• the failed package or Windows feature;
• the local path used;
• whether the file was readable;
• the matching manifest row and hash;
• the relevant log excerpt;
• the remediation and rerun result.

Do not respond to a missing-source error by temporarily opening general internet access to the server. Fix the controlled source or raise the required network change explicitly.

Verify before running SharePoint Setup

Do not stop at a green installer window.

Verify:

1. PrerequisiteInstaller.exe returns success after any restart cycle;
2. the log has no unresolved failed component;
3. the required Windows roles/features are installed;
4. .NET Framework 4.8 is present at the expected servicing level;
5. the applicable Visual C++ runtime is installed;
6. the OS and SharePoint edition still match the support matrix;
7. the server can reach the intended SQL and domain services through approved routes;
8. the complete evidence pack is retained;
9. the next farm server will use the same approved source.

Only then move to SharePoint product installation and farm configuration.

What not to do

• Do not install .NET 8 because an SPFx development tool or unrelated service uses it.
• Do not install PowerShell 7 as a SharePoint prerequisite.
• Do not add old AppFabric, Sync Framework or SQL Native Client packages from a different SharePoint edition.
• Do not publish invented package names, CVEs, cumulative-update hashes or “tested tenant” results.
• Do not use a connected server's successful installation as proof that the offline source is complete.
• Do not mix prerequisite packages and farm update packages without separate ownership and evidence.
• Do not call an unsupported Windows/SharePoint combination successful because Setup completed.

Frequently asked questions

Can SharePoint Server prerequisites be installed without internet access?

Yes. Microsoft documents using PrerequisiteInstaller.exe with local files or a network share, including a local Windows Features on Demand source.

Does SharePoint Server Subscription Edition require .NET 8?

No. Microsoft's current Subscription Edition prerequisite page specifies .NET Framework 4.8. Do not add .NET 8 unless a separate, documented workload on that server genuinely requires it.

What does prerequisite installer exit code 1001 mean?

Microsoft documents code 1001 as a pending restart that blocks installation. Restart through your change process, then continue and verify the new installer result.

What does exit code 3010 mean?

Code 3010 means a restart is required. After restarting, continue the prerequisite installation and do not proceed to SharePoint Setup until the installer and logs show success.

Can I reuse one offline prerequisite folder for every SharePoint version?

No. The required packages and switches differ between Subscription Edition, 2019, 2016 and older products. Build a manifest from the Microsoft requirements page for the exact edition and operating system.

If you are preparing an offline farm build and want another pair of eyes on the manifest and restart logic, join the SharePoint & Teams Admins Space. Bring the exact SharePoint edition, Windows build and a redacted manifest—never product keys or secrets.