Quantcast
Channel: AutoSPInstaller
Viewing all articles
Browse latest Browse all 2279

Commented Unassigned: SharePoint 2013\Windows 2012 Post deployment steps [20764]

$
0
0
Good day,

A few observations...

Following multiple trial runs, I now have scripts that successfully install 2 load-balanced front ends & 1 App\Central Admin server on windows 2012 & SharePoint 2013. These are full SP code\CU's & config deployments, but I've left the pre-req's in place after manually installing them to get past the re-boots...

The configuration (for others who want to try, I've attached the XML file, less passwords), creates a main site with a search center & all services running on the App server. It also creates a dedicated MySite host web app\site.

One of the things I noticed, if I used server hostnames in the URL's, then the links to Newsfeed\SkyDrive were stamped with that hostname URL, negating the load balancing, but by configuring the URL as a DNS object got around this problem, I also added SPN's as needed.

To get a reliable install I had to ensure that the "SharePoint Web Services" site was actually running, to do this I added the start site command in 2 places, i.e.

Write-Host -ForegroundColor White " - Creating Site Collection `"$siteURL`"..."
__start-website "SharePoint Web Services"__
$site = New-SPSite -Url $siteURL -OwnerAlias $ownerAlias -SecondaryOwner $env:USERDOMAIN\$env:USERNAME -ContentDatabase $siteDatabase -Description $siteCollectionName -Name $siteCollectionName -Language $LCID @templateSwitch @hostHeaderWebAppSwitch -ErrorAction Stop

and

Write-Host -ForegroundColor White " - Applying object cache accounts to `"$url`"..."
$wa.Properties["portalsuperuseraccount"] = $superUserAcc
Set-WebAppUserPolicy $wa $superUserAcc "Super User (Object Cache)" "Full Control"
$wa.Properties["portalsuperreaderaccount"] = $superReaderAcc
Set-WebAppUserPolicy $wa $superReaderAcc "Super Reader (Object Cache)" "Full Read"
$wa.Update()
Write-Host -ForegroundColor White " - Done applying object cache accounts to `"$url`""
__start-website "SharePoint Web Services"__
}

After a few runs I always have to manually:

Remove the SharePoint services AD account from the local administrators group, even though the log says otherwise:
- Adding Managed Accounts...
- Enabling Secondary Logon service...
- Starting Secondary Logon service...
- Account "sp13\svc_sp_svcs:
- Creating local profile for sp13\svc_sp_svcs...
- Adding to local Admins (*temporarily*)...Done.
- Removing from local Admins...Done.
- Done.

allied to the above are the setting of appropriate users to the following services:

Claims to windows token service - sp13\svc_sp_c2wts
Document Conversions Launcher Service - service account not "local service"
Document Conversions Load Balancer Service - service account not "local service"
User Profile Synchronization Service - sp13\svc_sp_adsync, this account has the required delegated AD rights

This is an "Enterprise" deployment but I have to enable "Enable Features on existing sites" from Central Admin. I would have added it to the powershell script if I could find the definitive answer for the command, most sites resort to using stsadm :(

Sometimes I get the "Product / patch installation or server upgrade required" error message, but just reanalysing, usually fixes it.

As this is a clean test system, then I always get the "People search relevance is not optimized when the Active Directory has errors in the manager reporting structure", fixed by adding a profile leader.

If I come across any more, I'll add them here...
Comments: ** Comment from web user: brianlala **

Somewhat un-intuitively I know, but there should be no need to manually start that SharePoint Web Services site or app pool. See http://www.harbar.net/archive/2009/12/04/more-on-sharepoint-2010-application-pools.aspx

Brian


Viewing all articles
Browse latest Browse all 2279

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>