Installation gets stuck in "Waiting for sandboxed code service to start"

Dec 6, 2010 at 12:13 PM

Several times, the SharePoint installation gets stuck in "Waiting for sandboxed code service to start" with the progress dots eventually covering the entire screen. I've waited up to an hour before aborting. The OS is Windows Server 2008 R2 (x64).

Does anyone know what could be the cause for this?

Thanks for any insights and for a fantastic project!

Coordinator
Dec 6, 2010 at 12:33 PM
This usually means that something went wrong during the farm config portion of the script and doesn't indicate a problem with the sandboxed code service itself. Review the log file (saved to desktop) for errors or indications as to why farm setup didn't succeed. Brian
Dec 6, 2010 at 3:35 PM

Thanks for your quick reply. I'll check the log thoroughly when (if!) it happens again!

Keep up the great work, this is a fabulous resource!

Coordinator
Dec 7, 2010 at 12:42 AM
Cheers
Dec 11, 2010 at 11:11 AM

Hello,

i get the same error.

Can you tell me, what did i have to do, that i can resolve the problem.

Thanks,

Horst

Jan 10, 2011 at 2:09 PM

FYI. When also installing a languagepack, I noticed the script hangs on this service. Restarting the script successfully starts the sandboxed code service, but stops at the next service installed. Etc.

Jan 10, 2011 at 2:49 PM

Hello banav,

thanks for your reply !!!

that means, don't install the language pack at default install.

Install them after the AutoSPInstaller ist ready?

Works the script - AutoSPInstaller if you doesn't install the language pack at default in your situation?

Horst

Jan 21, 2011 at 3:16 PM

I was experiencing this same issue and found a workaround. In my configuration file, I included fully qualified domain names for all of my server connections. In the AutoInstallerFunctions.ps1 file, on line 735 is the following line:

$SandboxedCodeService = $SandboxedCodeServices | ? {$_.Server.Address -eq $env:COMPUTERNAME}

Instead of returning the intended service, it returned null. I did some queries and found that the sandboxed code service instance that was configured in my environment was using the full qualified domain name of the server rather than just the netbios name that gets returned via $env:COMPUTERNAME.

I changed line 735 to include the FQDN of my server and now the script executes without any problems.

Coordinator
Jan 22, 2011 at 9:59 PM

Thanks! I might consider either adding inline comments to the config file advising not to use FQDNs, or else just changing the line (and similar references elsewhere) to something like:

$SandboxedCodeService = $SandboxedCodeServices | ? {$_.Server.Address -like "$env:COMPUTERNAME*"}

To better handle cases where FQDNs are used.

Brian

Jan 24, 2011 at 3:50 PM

I added the following to my file....

$SandboxedCodeService = $SandboxedCodeServices | ? {$_.Server.Address -eq $env:COMPUTERNAME -or $_.Server.Address -eq "$env:COMPUTERNAME.$env:USERDNSDOMAIN"}

I ran into several other problems because I was using FQDNs and had to make similar changes throughout the ps1 file. My customer typically uses FQDNs for all of their installations, so doing something like this would be helpful.

Thanks!

Doug