included a comment to address app pool names.
Not much bloat in this.
I'd push for having in the script to fix manual or find/replace edits of raw xml files.
XSD overkill ?
I have this same error but don't see the issue. Please help.
Guy
For anyone who runs into this, the problem is that the SharePoint 2013 installer doesn't recognize .Net Framework 4.6 (or later) - so if you've installed the 4.6 framework, you can't move forward.
You *can* uninstall the .Net Fx 4.6. The problem here is that every time MSFT updates the damn thing, they change the KB number, and there's no easy way to find the new one. Currently the latest update that does it is KB3102467 - uninstall that from Add/Remove programs and SharePoint 2013 will install easily.
However, if they update the 4.6 framework again, you'll have to go hunting through your installed updates to find it. Obviously the number will be after 3102467.
I used this PowerShell to dump a list of installed updates to a CSV file:
```
$Session = New-Object -ComObject "Microsoft.Update.Session"
$Searcher = $Session.CreateUpdateSearcher()
$historyCount = $Searcher.GetTotalHistoryCount()
$Searcher.QueryHistory(0, $historyCount) | Select-Object Title, Description, Date,
@{name="Operation"; expression={switch($_.operation){
1 {"Installation"}; 2 {"Uninstallation"}; 3 {"Other"}
}}} | Export-Csv -NoType -Path c:\temp\Updates.csv
```
Then I opened the CSV in Excel, highlighted the column with the KB numbers, and did a find & replace - replace "KB" with "https://support.microsoft.com/en-us/kb/" and you've got a list of URLs that will open the page for the KB article. Then open each page until you find a .Net Framework 4.6 installer.
(This was because as of January 2016 there's no web service to resolve a KB number to an article description, and you can't scrape pages because they're dynamic - a javascript framework that fills the content after it loads. What I think of the TechNet team right now isn't suitable for mixed company)
That was the quickest way I could find. If you can do better, please leave a note here for posterity.
Hey Guys,
I'm seeing this too, only on the first run (if I have to re-run) AutoSPInstaller.
If I use AutoSPInstaller, I find that I can't use PSConfigUI.exe any more, it gets an access denied on a SharePoint folder (sorry, didn't take down the details, will grab it next time).
Thanks
Craig
With the pre-reqs failing, I found that by using brian's [AutoSPSourceBuilder](https://autospsourcebuilder.codeplex.com/) I was able to pre-download the correct set of pre-reqs, which were different from some other blog post I was working from.
Good spotting on the Web Apps, I'd already spotted the Distributed Cache issue, but not the FoundationWebApplication.
I ended up doing a restart of the computer between installation of binaries and configuration of the farm and then re-launching ASPI after an automatical logon. This solved the problem for me.
Added this in AutoSPInstallerFunctionsCustom.ps1:
```
Function RestartAfterBinaryInstallation([xml]$xmlinput) {
$restartedAfterBinaryInstallation = (Get-ItemProperty "HKLM:\SOFTWARE\AutoSPInstaller").RestartedAfterBinaryInstallation -eq "1"
if ($RestartedAfterBinaryInstallation -eq $false) {
New-ItemProperty -Path "HKLM:\SOFTWARE\AutoSPInstaller" -Name "RestartedAfterBinaryInstallation" -Value 1 -PropertyType "String" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" -Name "AutoAdminLogon" -Value 1 -PropertyType "String" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" -Name "DefaultDomainName" -Value $env:USERDOMAIN -PropertyType "String" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" -Name "DefaultUserName" -Value $env:USERNAME -PropertyType "String" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" -Name "DefaultPassword" -Value $password -PropertyType "String" -Force | Out-Null
New-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\WinLogon" -Name "AutoLogonCount" -Value 1 -PropertyType "Dword" -Force | Out-Null
Set-UserAccountControl 0
New-Item -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\" -Name RunOnce -ErrorAction SilentlyContinue | Out-Null
New-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\RunOnce" -Name AutoSPInstaller -Value "`"$env:dp0\AutoSPInstallerLaunch.bat`" `"$inputFile`"" -Force | Out-Null
Restart-Computer -ErrorAction SilentlyContinue
if (!$?)
{
Write-Warning "Restart failed; there may be (an) other user(s) logged in!"
$forceRestart = Read-Host -Prompt " - Do you want to force a restart? (y/n)"
if ($forceRestart -eq "y") {Restart-Computer -Force}
}
}
}
```
In AutoSPInstallerMain:.ps1
```
Function Setup-Farm
{
__ <...>
ConfigureLanguagePacks $xmlinput
__ RestartBinariesAfterInstallation $xmlinput # <--- ADDED
__ AddManagedAccounts $xmlinput
}
```
Notice, this doesn't handle installation on multiple servers. Maybe it works, maytbe not...
Brian, could you give us a complete AutoSPInstallerInput.xml-file that you know will work? I've tried the one made by autospinstaller.com with no success.
A little background: I've made a set of scripts for my company that creates a complete SharePoint developer environment (in Hyper-V) based on a settings.xml-file, all the way from creating an unattended installation of Windows Server, installation of AD, SQL and SharePoint and then all required dev-software (including Visual Studio). All this is done in a couple of hours with no user interventions needed since restarts and automatically logons are handled by the script(s). Having to manually restart AutoSPInstaller ruined that experience...
"-ge" means "Greater than or equal to". 16 is greater than 15, so the code will and does run.
Brian
What's the net result of your investigations? I haven't run into this myself, so not sure what to "fix" yet. Is it still happening for you with the Release Candidate?
Brian
I'm not sure that the password is ever displayed or saved anywhere (except of course the XML). So, closing this issue unless you feel there is a real and demonstrable security vulnerability.
Thanks,
Brian
The reason for this is your naming convention. One server name is a sub-string of the other. Try giving your servers names such as SP2013-SQL and SP2013-SP01.
HTH,
Brian
the fix I posted is ok. This is for SharePoint 2013 and not 2016. RTM version only.
the fix is:
add the function installIISRolePreSP1 to cutomfunctions
call the function in the beginning of pre-sp1 prerequisistes (windows 2012 R2) install
add the servermanager process gracefull kill in the pre-sp1 prereq install like I mention in the previous post.
Let me know if you need more info.
the Disable-ServerManagerlaunchOnLogon function is optional.
OK, I'm going to leave this as something affected users can implement themselves - as ostensibly the more permanent fix is to just go with 2013 SP1. Let me know if I've misinterpreted things though.
Brian
It's ok with me. It can be a problem though for those trying to install RTM first and SP1 in the same process. In this case it just does not work. I have an RTM iso and I add SP1 in the updates to install.
for those with a slipstreamed sp1 re-release iso this is not a problem.