autospinstaller Issue Tracker Rss Feed

Hi Brian,

Thank you for the incredible effort that you have put in to create this tool! It makes deployment such a piece of cake!!

Just realized that when the Distributed Cache service is being setup, the script is using the app pool account for the service; specifically it uses the ManagedAccount with CommonName="spservice".

I am referring to line# 1681 in the "AutoSPInstallerFunctions.ps1", function "UpdateProcessIdentity".
Specifically it is as shown below:
$managedAccountGen = Get-SPManagedAccount | Where-Object {$_.UserName -eq $($spservice.username)}

However the TechNet article (https://technet.microsoft.com/en-us/library/jj219613.aspx#changesvcacct) suggests that the "Farm Account" is used to setup the service.

Should this be changed to the default Farm Account?

Thank you
Ashok
Comments: Q&A

Hi Brian,

thanks for the prompt response.

i think I may have not clarified my statement or may have misunderstood the current default values used in the script. My apologies for that.

I see that the default managed account for the "spservice" currently uses CONTOSO\SP_Services. This tells me that all almost Service Applicaitions, except Search and some other using specific accounts, will be provisioned using the CONTOSO\SP_Services account.

I am not suggesting using separate account for each and every service, that will surely be an overkill. Just that, the script could have different CommonNames defined for each service with a default value set to CONTOSO\SP_Services. Folks could then choose to either go with a common account for all services or use specific domain accounts if they so choose to depending upon their requirements. It just makes it a little simpler to configure the farm.

Just a thought.

Thanks once again!
Ashok

I have just built 3 SharePoint 2016 Farm with December 2016 CU. All the 3 Farms had their Central admin content database requiring upgrade.

I had to run:

(Get-SPWebApplication -IncludeCentralAdministration | ? {$_.DefaultServerComment -match "SharePoint Central Administration V4"}).contentdatabases | Upgrade-SPContentDatabase

in order to fix it.
Comments: ** Comment from web user: josephsaad **

I agree that it is not an "AutoSPInstaller" issue. I tried without AutoSPInstaller and still got the same problem.

I am using the lastest version of AutoSPInstaller and I am getting the following error after the binaries are setup and at the beginning of installing service applications. I am using Server 2016 and sql server 2016 developer edition on a seperate se3rver 2016 server . I am setting up Sharepoint 2016 with a single web front end and separate database server in my lab. I have attached my input file as wel

- Waiting for Metadata service...Online
- Creating Metadata Service Application...
- Creating Metadata Service Application Proxy...
New-SPMetadataServiceApplicationProxy : ____The topology service is not available in the farm__.__
At E:\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2505 char:44
+ ... eAppProxy = New-SPMetadataServiceApplicationProxy -Name $metadataServ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Share...ataServiceProxy:SPCmdletNewMetadata
ServiceProxy) [New-SPMetadataServiceApplicationProxy], SPException
+ FullyQualifiedErrorId : Microsoft.SharePoint.Taxonomy.Cmdlet.SPCmdletNewMetadataServiceProx
y

- Failed to create Metadata Service Application Proxy
At E:\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:2506 char:32
+ ... (-not $?) { Throw " - Failed to create Metadata Service Application P ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: ( - Failed to cr...plication Proxy:String) [], Ru
ntimeException
+ FullyQualifiedErrorId : - Failed to create Metadata Service Application Proxy

--------------------------------------------------------------
- Script halted!
- Error provisioning the Managed Metadata Service Application
Press any key to exit...

rerunning the AutoSpInstaller does not work as it never gets past this error.

Hello

I want to install a simple single server farm SP2013 Enterprise with your script, and after following all the instructions, Unfortunately at the " - Installing SharePoint 2013 binaries......." step the Product key dialog shows up as shown on the screenshot. Why this is happening ?

Shouldn't the installation proceeds by itself and picks the PIDKey value from the XML file? Why it doesn't?

One-Single farm info:
OS: Windows 2012 R2
SQL Server 2012 SP2
SP2013 media: SP1 Slipstream (Meaning the downloading ISO from MSDN contains SharePoint with SP1 together)

<Configuration Environment="SP2013Farm" Version="3.99.51">
<Install SPVersion="2013">
<ConfigFile>SP2013Farm.xml</ConfigFile>
<InstallDir>C:\Program Files\Microsoft Office Servers</InstallDir>
<DataDir>C:\Program Files\Microsoft Office Servers\SharePoint2013\Data</DataDir>
<PIDKey>MY-100%-CORRECT-KEY-VALUE</PIDKey>
<SKU>Enterprise</SKU>
<OfflineInstall>false</OfflineInstall>
<PauseAfterInstall>false</PauseAfterInstall>
<RemoteInstall Enable="false">
<ParallelInstall>false</ParallelInstall>
</RemoteInstall>
<AutoAdminLogon Enable="true">
<Password>Password</Password>
</AutoAdminLogon>

Could you please help out? Am I doing anything wrong?

Thank you !
Comments: ** Comment from web user: sqlsolver **

Experiencing this issue as well. Runs like a top through binary install until it gets to the updates (tried locating these in each of slipstream in the SP media's updates folder and placed in the updates folder parallel to the SharePoint folder, same error either way):

Setup log:
````
2017/02/06 14:46:34:246::[1356] Loading package metadata: D:\AutoSPInstaller\SP\2016\SharePoint\global\Wss\sts.xml
2017/02/06 14:46:34:246::[1356] Searching for patches for the current chained install in: D:\AutoSPInstaller\SP\2016\SharePoint\updates
2017/02/06 15:13:28:717::[1356] User attempting to cancel setup. Confirming...
````
Canceled out as soon as the box requesting the license key came up.
Transcript:
````
- Script halted!
- Could not find SharePoint Server Setup log file!
````
Setup log was there and easily visible on the server navigating to %temp%
Install was done from UNC path, not on local server.

Had been dragging custom configuration file onto the launch file to kick off, also tried copying it to AutoSPInstallerInput and then starting the .bat as an admin.

Tried removing the name of the custom configuration file from between the ConfigFile tags as seems to be suggested above, got 'Cannot find the specified configuration file... [path]AutoSPInstaller'

While performing a multi-server installation all servers subsequent to the App server AutoSPInstaller was initiated from failed to join the existing farm and attempted to recreate the configuration database as shown in the following screen shot:
![Image](https://drive.google.com/file/d/0By2D_as8v9bmSGlDS3gtU1hHcEU/view?usp=sharing)
Servers were WS2012 R2 with no internet access (offline install/parallel/remote).

SQL Server connectivity to the configuration database was verified using the ODBC tool on each server where this occurred.

The next step was to start the UI version of psconfig to see if it could locate the farm configuration database and the following error message popped up:
![Image](https://drive.google.com/file/d/0By2D_as8v9bmaUY1THZsWjdlWlU/view?usp=sharing)
Ignoring the error message allowed the configuration wizard to start and it easily found the farm and its configuration database. Closed the wizard since we didn't want to configure via UI.

Next wondered whether the DLL was actually missing, or just not registered. It was not present in the SYSTEM32 folder for the farm we were configuring, but was present on another previously (successfully) installed farm. Found [Vlad Castrinescu's post regarding this .dll belonging to a specific Windows Update](https://absolute-sharepoint.com/2015/12/sharepoint-2016-this-program-cant-start-because-api-ms-win-crt-heap-l1-1-0-dll-is-missing.html) package, however these servers are automatically patched so no option to install the update package Additionally, the set of servers that had the update showed it had been installed the same day as SharePoint, so it was likely a product of the SharePoint installation rather than a Windows Update process. Discovered the missing DLL in the root folder of the SharePoint 2016 installation media. Although AutoSPInstaller had reported both the prerequisites and the SharePoint binaries had installed correctly, something had not gone well or the group of DLLs present in the installation media would be present.

Noted that the pre-reqs downloaders [here](https://github.com/DanHolme/SP2016-Prereq-Downloader/blob/master/Download-SP2016-Prereqs.ps1) and [here](https://github.com/brianlala/AutoSPSourceBuilder/blob/master/AutoSPSourceBuilder.xml), as of the date of this post, both link to a different set of the C++ DLLs than [TechNet's SharePoint installation guide](https://technet.microsoft.com/en-us/library/cc262485(v=office.16).aspx#Anchor_5) does. Also noticed TechNet version of the VS2015 redist is 14,231 KB compared to 7019 KB for the version provided in the first two. Thus, even though the install had gone fine using the pre-req builder versions, updated the offline install files for the prerequisites to match the TechNet links. Uninstalled SharePoint on all the problem servers and manually installed those two pre-reqs, then checked to make sure the DLL was present.

Following the above AutoSPInstaller was able to perform a successful remote install on all the servers in the farm. Should there be a check to verify the VS2012/15 DLLs are present before attempting to join the farm?

While performing a multi-server installation all servers subsequent to the App server AutoSPInstaller was initiated from failed to join the existing farm and attempted to recreate the configuration database as shown in the following screen shot (open images in new tab if not displayed):
![Image](https://drive.google.com/file/d/0By2D_as8v9bmSGlDS3gtU1hHcEU/view?usp=sharing)
Servers were WS2012 R2 with no internet access (offline install/parallel/remote).

SQL Server connectivity to the configuration database was verified using the ODBC tool on each server where this occurred.

The next step was to start the UI version of psconfig to see if it could locate the farm configuration database and the following error message popped up:
![Image](https://drive.google.com/file/d/0By2D_as8v9bmaUY1THZsWjdlWlU/view?usp=sharing)
Error text:
"The program can't start because api-ms-win-crt-heap-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."
Ignoring the error message allowed the configuration wizard to start and it easily found the farm and its configuration database. Closed the wizard since we didn't want to configure via UI.

Next wondered whether the DLL was actually missing, or just not registered. It was not present in the SYSTEM32 folder for the farm we were configuring, but was present on another previously (successfully) installed farm. Found [Vlad Castrinescu's post regarding this .dll belonging to a specific Windows Update](https://absolute-sharepoint.com/2015/12/sharepoint-2016-this-program-cant-start-because-api-ms-win-crt-heap-l1-1-0-dll-is-missing.html) package, however these servers are automatically patched so no option to install the update package Additionally, the set of servers that had the update showed it had been installed the same day as SharePoint, so it was likely a product of the SharePoint installation rather than a Windows Update process. Discovered the missing DLL in the root folder of the SharePoint 2016 installation media. Although AutoSPInstaller had reported both the prerequisites and the SharePoint binaries had installed correctly, something had not gone well or the group of DLLs present in the installation media would be present.

Noted that the pre-reqs downloaders [here](https://github.com/DanHolme/SP2016-Prereq-Downloader/blob/master/Download-SP2016-Prereqs.ps1) and [here](https://github.com/brianlala/AutoSPSourceBuilder/blob/master/AutoSPSourceBuilder.xml), as of the date of this post, both link to a different set of the C++ DLLs than [TechNet's SharePoint installation guide](https://technet.microsoft.com/en-us/library/cc262485(v=office.16).aspx#Anchor_5) does. Also noticed TechNet version of the VS2015 redist is 14,231 KB compared to 7019 KB for the version provided in the first two. Thus, even though the install had gone fine using the pre-req builder versions, updated the offline install files for the prerequisites to match the TechNet links. Uninstalled SharePoint on all the problem servers and manually installed those two pre-reqs, then checked to make sure the DLL was present.

Following the above AutoSPInstaller was able to perform a successful remote install on all the servers in the farm. Should there be a check to verify the VS2012/15 DLLs are present before attempting to join the farm?
Comments: ** Comment from web user: brianlala **

This is all good troubleshooting, and glad to hear it's resolved, but... how is this an "issue" with AutoSPInstaller? Remember, this forum is specifically for suspected issues/bugs with the _script itself _- not to report on or log issues with Windows, SharePoint, or any of its prerequisites.

As a stretch, one could argue that the check for that DLL could be a feature request, but since (as it's the first I've heard of it) the problem is quite rare, I'm not sure that it would warrant adding more complexity to AutoSPInstaller.

Having said that, this would be a good item to bring up in the Discussions part of this CodePlex site in case anyone runs into it, or maybe even MSDN/TechNet/Stack Overflow etc.

Thanks for raising this, I'll go ahead and close the issue though :)

Brian

While performing a multi-server installation all servers subsequent to the App server AutoSPInstaller was initiated from failed to join the existing farm and attempted to recreate the configuration database as shown in the following screen shot (open images in new tab if not displayed):
![Image](https://drive.google.com/file/d/0By2D_as8v9bmSGlDS3gtU1hHcEU/view?usp=sharing)
Servers were WS2012 R2 with no internet access (offline install/parallel/remote).

SQL Server connectivity to the configuration database was verified using the ODBC tool on each server where this occurred.

The next step was to start the UI version of psconfig to see if it could locate the farm configuration database and the following error message popped up:
![Image](https://drive.google.com/file/d/0By2D_as8v9bmaUY1THZsWjdlWlU/view?usp=sharing)
Error text:
"The program can't start because api-ms-win-crt-heap-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."
Ignoring the error message allowed the configuration wizard to start and it easily found the farm and its configuration database. Closed the wizard since we didn't want to configure via UI.

Next wondered whether the DLL was actually missing, or just not registered. It was not present in the SYSTEM32 folder for the farm we were configuring, but was present on another previously (successfully) installed farm. Found [Vlad Castrinescu's post regarding this .dll belonging to a specific Windows Update](https://absolute-sharepoint.com/2015/12/sharepoint-2016-this-program-cant-start-because-api-ms-win-crt-heap-l1-1-0-dll-is-missing.html) package, however these servers are automatically patched so no option to install the update package Additionally, the set of servers that had the update showed it had been installed the same day as SharePoint, so it was likely a product of the SharePoint installation rather than a Windows Update process. Discovered the missing DLL in the root folder of the SharePoint 2016 installation media. Although AutoSPInstaller had reported both the prerequisites and the SharePoint binaries had installed correctly, something had not gone well or the group of DLLs present in the installation media would be present.

Noted that the pre-reqs downloaders [here](https://github.com/DanHolme/SP2016-Prereq-Downloader/blob/master/Download-SP2016-Prereqs.ps1) and [here](https://github.com/brianlala/AutoSPSourceBuilder/blob/master/AutoSPSourceBuilder.xml), as of the date of this post, both link to a different set of the C++ DLLs than [TechNet's SharePoint installation guide](https://technet.microsoft.com/en-us/library/cc262485(v=office.16).aspx#Anchor_5) does. Also noticed TechNet version of the VS2015 redist is 14,231 KB compared to 7019 KB for the version provided in the first two. Thus, even though the install had gone fine using the pre-req builder versions, updated the offline install files for the prerequisites to match the TechNet links. Uninstalled SharePoint on all the problem servers and manually installed those two pre-reqs, then checked to make sure the DLL was present.

Following the above AutoSPInstaller was able to perform a successful remote install on all the servers in the farm. Should there be a check to verify the VS2012/15 DLLs are present before attempting to join the farm?
Comments: Likely issue with Windows/SP/Prerequisite installer.

While performing a multi-server installation all servers subsequent to the App server AutoSPInstaller was initiated from failed to join the existing farm and attempted to recreate the configuration database as shown in the following screen shot (open images in new tab if not displayed):
![Image](https://drive.google.com/file/d/0By2D_as8v9bmSGlDS3gtU1hHcEU/view?usp=sharing)
Servers were WS2012 R2 with no internet access (offline install/parallel/remote).

SQL Server connectivity to the configuration database was verified using the ODBC tool on each server where this occurred.

The next step was to start the UI version of psconfig to see if it could locate the farm configuration database and the following error message popped up:
![Image](https://drive.google.com/file/d/0By2D_as8v9bmaUY1THZsWjdlWlU/view?usp=sharing)
Error text:
"The program can't start because api-ms-win-crt-heap-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem."
Ignoring the error message allowed the configuration wizard to start and it easily found the farm and its configuration database. Closed the wizard since we didn't want to configure via UI.

Next wondered whether the DLL was actually missing, or just not registered. It was not present in the SYSTEM32 folder for the farm we were configuring, but was present on another previously (successfully) installed farm. Found [Vlad Castrinescu's post regarding this .dll belonging to a specific Windows Update](https://absolute-sharepoint.com/2015/12/sharepoint-2016-this-program-cant-start-because-api-ms-win-crt-heap-l1-1-0-dll-is-missing.html) package, however these servers are automatically patched so no option to install the update package Additionally, the set of servers that had the update showed it had been installed the same day as SharePoint, so it was likely a product of the SharePoint installation rather than a Windows Update process. Discovered the missing DLL in the root folder of the SharePoint 2016 installation media. Although AutoSPInstaller had reported both the prerequisites and the SharePoint binaries had installed correctly, something had not gone well or the group of DLLs present in the installation media would be present.

Noted that the pre-reqs downloaders [here](https://github.com/DanHolme/SP2016-Prereq-Downloader/blob/master/Download-SP2016-Prereqs.ps1) and [here](https://github.com/brianlala/AutoSPSourceBuilder/blob/master/AutoSPSourceBuilder.xml), as of the date of this post, both link to a different set of the C++ DLLs than [TechNet's SharePoint installation guide](https://technet.microsoft.com/en-us/library/cc262485(v=office.16).aspx#Anchor_5) does. Also noticed TechNet version of the VS2015 redist is 14,231 KB compared to 7019 KB for the version provided in the first two. Thus, even though the install had gone fine using the pre-req builder versions, updated the offline install files for the prerequisites to match the TechNet links. Uninstalled SharePoint on all the problem servers and manually installed those two pre-reqs, then checked to make sure the DLL was present.

Following the above AutoSPInstaller was able to perform a successful remote install on all the servers in the farm. Should there be a check to verify the VS2012/15 DLLs are present before attempting to join the farm?
Comments: ** Comment from web user: sqlsolver **

It could be considered an issue because AutoSPInstaller provides an interface between you and the installation, and the interface is happily reporting pre-reqs are done even though these DLLs are missing. You're right, whether it would warrant 'adding more complexity' in the form of checking whether those files exist after the pre-req install depends on how often the issue is actually encountered. This morning a Google search for the word, '[api-ms-win-crt-heap-l1-1-0.dll](https://www.google.com/search?q=api-ms-win-crt-heap-l1-1-0.dll&rlz=1C1CHBF_enUS720US720&oq=api-ms-win-crt-heap-l1-1-0.dll&aqs=chrome..69i57j69i61&sourceid=chrome&ie=UTF-8)' brings up 23,500 results with first page headline titles all about what to do when it's gone missing, so if that problem persists it may be worthwhile to provide some cover for it.

That's my suggestion for today, and I'll follow yours to flag this in other discussion areas. AutoSPInstaller is an absolutely awesome piece of work that allows me to provide repeatable builds with SP2016 MinRoles intact, a functioning search topology and UPS, legible database names and more. Thanks so much for all your hard work on a really outstanding contribution to the SharePoint community.

If the SuperReader and SuperUser Account exist in another domain, these accounts are marked as invalid. The problem is caused by the method:

function userExists ([string]$name)

In my view this function should use a domain parameter to work properly.
Comments: ** Comment from web user: KevinColeMCM **

I also had this issue where the server was on DOMAINA and user accounts were on DOMAINB

The option I used instead however was to create an entry in the autospinstallerconfig.xml and modify the functions so that an LDAP path is passed into the user exists method if it is provided in the config file.

Updated userExists function to accept ldap option for override:
```
# ====================================================================================
# Func: userExists
# Desc: "Here is a little powershell function I made to see check if specific active directory users exists or not."
# From: http://oyvindnilsen.com/powershell-function-to-check-if-active-directory-users-exists/
# ====================================================================================
function userExists ([string]$name, [string]$ldap)
{
#written by: Øyvind Nilsen (oyvindnilsen.com)
[bool]$ret = $false #return variable
$domainRoot = [ADSI]"$ldap"
$dirSearcher = New-Object System.DirectoryServices.DirectorySearcher($domainRoot)
$dirSearcher.filter = "(&(objectClass=user)(sAMAccountName=$name))"
$results = $dirSearcher.findall()
if ($results.Count -gt 0) #if a user object is found, that means the user exists.
{
$ret = $true
}
return $ret
}
```

Updated foreach block in AutoSPInstallerFunctions.ps1 :: ValidateCredentials
```
foreach ($account in $accountsToCheck)
{
$domain,$accountName = $account -split "\\"
Write-Host -ForegroundColor White " - Account `"$account`"..." -NoNewline
if (!(userExists $accountName -ldap $xmlinput.Configuration.Farm.CustomLdap))
{
Write-Host -BackgroundColor Red -ForegroundColor Black "Invalid!"
$acctInvalid = $true
}
else
{
Write-Host -ForegroundColor Black -BackgroundColor Green "Verified."
}
}
```

Added under <Farm> element into config xml:
```
<Configuration Environment="PILOT" Version="3.99.60">
<Farm>
<CustomLdap>LDAP://DC=LAN,DC=local</CustomLdap>
</Farm>
</Configuration>
```

Installation fails when using SharePoint 2016 binaries in other Language
Bug is found in AutoSPInstallerMain.ps1, in function Run-Install
It hardcodes the name of the SharePoint Management Shell link, but when binaries is in other Language, the link isn't correct

Set-ShortcutRunAsAdmin -shortcutFile "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SharePoint $spYear Products\SharePoint $spYear Management Shell.lnk"

Hi Brian,

not a AutoSP bug really, but if you slipstream SP2016 with a CU (using autospbuilder), it works on windows server 2016, but doesn't work on 2012 R2.

- Using 2012 R2 RTM, .NET 4.6 fails to install because of update 1 missing
- Using 2012 R2 update1, the sharepoint setup show error messages (stsadm.exe crashes)

Thanks for the excellent work again. I used the script to build a "push" farm to a cloud SSA (without any webapplications), and it saves a lot of time, like it always does ;)

My config snippet file is :

<WebApplication Name="PORTAL">
...
...
<Url>http://sptdev</Url>
<Port>8086</Port>
<Database>
```
<Name>Portal </Name>

```
</Database>
<SiteCollections>
<SiteCollection siteUrl="http://sptdev:8086">
<CustomDatabase>MyCustomDB</CustomDatabase>
</SiteCollection>
<SiteCollections>

#Issue happens in file : AutoSpInstallerFunction.ps1 Line: 2286

1. It checks if <CustomDatabase> contains value or empty.
2. If its empty, create a new content db.

The line below, it uses $webApp.Url value which is (http://sptdev) without the port number thus throwing an error that the webapp cannot be found.

New-SPContentDatabase -Name $siteDatabase -WebApplication (Get-SPWebApplication $webApp.url) | Out-Null

Issue happens in file : AutoSpInstallerFunction.ps1 Line: 2286

1. It checks if <CustomDatabase> contains value or empty.
2. If its empty, create a new content db.

The line below, it uses $webApp.Url value which is (http://sptdev) without the port number thus throwing an error that the webapp cannot be found.

#Offending Line
New-SPContentDatabase -Name $siteDatabase -WebApplication (Get-SPWebApplication $webApp.url) | Out-Null

#Potential Solution 1 :
This could be just getting the value from the $siteURL in line 2830 and concatenate the string to get the webapp url.

#Potential Solution 2
Create a new variable in line 2711 called $webAppUrl = $webApp.url + ":" + $webApp.Port
and use the $webAppUrl in the function as a reference to webApp URL.

I have a issue went AutoSPInstaller try to load the management Shell for SharePoint 2016

Configuration
Windows 2016
SQL 2016

here the error

- Setting SharePoint Management Shell to run as Administrator...
- Script halted!

Exception:
System.Management.Automation.MethodInvocationException: Exception calling "ReadAllBytes" with "1" argument(s): "Could not find file 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SharePoint 2016 Products\SharePoint 2016 Management Shell.lnk'." --->
System.IO.FileNotFoundException: Could not find file 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SharePoint 2016 Products\SharePoint 2016 Management Shell.lnk'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights,
Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES
secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare
share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy, Boolean
useLongPath, Boolean checkHost)
at System.IO.File.InternalReadAllBytes(String path, Boolean checkHost)
at CallSite.Target(Closure , CallSite , Type , Object )
--- End of inner exception stack trace ---

at System.Management.Automation.ExceptionHandlingOps.CheckActionPreference(FunctionContext
funcContext, Exception exception)
at System.Management.Automation.Interpreter.ActionCallInstruction`2.Run(InterpretedFrameFrame)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrameframe)
at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrameframe)
TargetObject :
CategoryInfo : NotSpecified: (:) [], MethodInvocationException
FullyQualifiedErrorId : FileNotFoundException
ErrorDetails :
InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : at Set-ShortcutRunAsAdmin, D:\Infra\AutoSPInstaller\AutoSPInstallerFunctions.ps1: line 7723
at Run-Install, D:\Infra\AutoSPInstaller\AutoSPInstallerMain.ps1: line 194
at <ScriptBlock>, D:\Infra\AutoSPInstaller\AutoSPInstallerMain.ps1: line 398
at <ScriptBlock>, <No file>: line 1
PipelineIterationInfo : {}
PSMessageDetails :

Interesting, it's as though the shortcut for the management shell wasn't created properly. It's not actually trying to load the management shell, it's just setting the shortcut to run as administrator. Can you check if the shortcut exists (either in the specified path, or in your Start Menu)? If the shortcut doesn't exist then there may be something amiss with your SharePoint installation in general.

Brian

I manage to solve my probleme to force using short path in the link, ill try to find why Server 2016 in powershell causing this issue.

replace
Set-ShortcutRunAsAdmin -shortcutFile "$env:ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft SharePoint $spYear Products\SharePoint $spYear Management Shell.lnk"

for

Set-ShortcutRunAsAdmin -shortcutFile "$env:ProgramData\Microsoft\Windows\STARTM~1\Programs\MICROS~3\SHAREP~1.LNK"

Found another bug, perhaps there should be a check to make sure Token Service is running before allowing the script to attempt to build a Secure Store Service:

- Provisioning Secure Store Service Application...
- Starting Secure Store Service Instance...
- Waiting for Secure Store service...Online
- Creating Secure Store Service Application...
- Creating Secure Store Service Application Proxy...
- Done creating Secure Store Service Application.
- Creating the Master Key...
Update-SPSecureStoreMasterKey : Secure Store Service did not performed the operation.
At C:\USPTO\AutoSPInstaller_back\SP\AutoSPInstaller\AutoSPInstallerFunctions.ps1:3939 char:13
+ Update-SPSecureStoreMasterKey -ServiceApplicationProxy $secureStore. ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidData: (Microsoft.Offic...eStoreMasterKey:SPUpdateSPSecureStoreMasterKey) [Update-
SPSecureStoreMasterKey], FaultException
+ FullyQualifiedErrorId : Microsoft.Office.SecureStoreService.PowerShellCmdlet.SPUpdateSPSecureStoreMasterKey

- Creating the Application Key...
- Done creating/configuring Secure Store Service Application.
Comments: ** Comment from web user: AshokGopalan **

Found the same issue when the first App server configured in the farm enabled the Secure Store Service and the second App server was also selected to provision the service in the AutoSpInstaller XML file.

Fails at the following line
Write-Host -ForegroundColor White " - Creating the Master Key..."
Update-SPSecureStoreMasterKey -ServiceApplicationProxy $secureStore.Id -Passphrase $farmPassphrase

Could it be because the farm passphrase used has not changed and the Update-SPSecureStoreMasterKey is trying to update with the same passphrase? If the Service Application is already created, do we need to update the master key again if you are only adding additional servers for this service?

I was running the script after modifying a few things to reprovision search and the web app had a different name by then but the same url. The script will try (and fail) to create the web app with the same url.

This is the fix:

In AutoSPInstallerFunctions.ps1
in Function CreateWebApp
Change line:

$getSPWebApplication = Get-SPWebApplication | Where-Object {$_.DisplayName -eq $webAppName }

To this:

$getSPWebApplication = Get-SPWebApplication | Where-Object {$_.DisplayName -eq $webAppName __-or $_.Url -eq $url__}

Closed Unassigned: Distributed Cache service account (during setup) [22458]

Commented Unassigned: Distributed Cache service account (during setup) [22458]

Commented Unassigned: Central admin database need upgrade [22445]

Created Unassigned: AutoSPInstaller for Sharepoint 2016 failing topology service is not available [22464]

Commented Unassigned: AutoSPInstaller for Sharepoint 2016 failing topology service is not available [22464]

Commented Task: Product key dialog shows up during installation ? [22015]

Created Unassigned: "No Existing Farm Found" on multi-server remote install [22478]

Commented Unassigned: "No Existing Farm Found" on multi-server remote install [22478]

Closed Unassigned: "No Existing Farm Found" on multi-server remote install [22478]

Commented Unassigned: "No Existing Farm Found" on multi-server remote install [22478]

Commented Issue: Account invalid (SuperReader, SuperUser) [20601]

Created Unassigned: Installation fails when using SharePoint 2016 binaries in other language [22489]

Created Unassigned: Slipstream SP2016 install fails on 2012 R2 [22505]

Created Unassigned: a custom database for a site collection [22506]

Created Unassigned: AutoSPInstaller cannot load SP management Shell [22512]

Commented Unassigned: AutoSPInstaller cannot load SP management Shell [22512]

Commented Unassigned: AutoSPInstaller cannot load SP management Shell [22512]

Edited Issue: AutoSPInstaller cannot load SP management Shell [22512]

Commented Unassigned: Update-SPSecureStoreMasterKey : Secure Store Service did not performed the operation. [22184]

Created Unassigned: Issue with pre-existing web app with same url, diff display name. [22536]