I had trouble on SharePoint Configuration “Step 3 – Configure Database” when installing the SharePoint 2016 Preview on a single developer VM.
Step 3 never completed its processing after running for 8+ hours.
Here’s my work around:
- Disable UAC via the registry setting and reboot.
- Use the New-SPConfigurationDatabase powershell script to create the configdb.
- Run PSConfigUI to let the rest of the configuration operations (4 through 10) complete quickly.
The updated New-SPConfigurationDatabase command has a new mandatory parameter called -localserverrole. I specified “SingleServerFarm” for the server role. The command prompts for the other input parameters.
New-SPConfigurationDatabase finished successfully, but it did take hours to run.
Note: I’m happy with my development VM performance which is due in large part to SSD disk from which it runs. I recommend this piece of hardware on your SharePoint 2016 development rig.
Worked through a search issue last week. Hope this post helps to give some guidance.
We had a Default Zone URL called http://foo
It was extended to FBA on the Internet Zone with URL called http://bar
We configured a content source that crawled the Internet Zone, i.e. we crawled http://bar.
Here are the results:
http://foo (Default Zone Url)
- The search results web part worked correctly when viewed through http://foo
- The configured Result Query also was honored to help filter results.
- The search results links resolved as http://foo.
http://bar (Internet Zone Url)
- The search results web part returned all results when viewed through http://bar
- The search results links resolved as http://bar.
- The configured Result Query was NOT honored to help filter results.
We focused first on permissions with no resolution.
Then we started looking at the AAMs role in configuration.
After some initial positive results, we discovered this article explaining the situation: http://blogs.msdn.com/b/sharepoint_strategery/archive/2014/07/08/problems-when-crawling-the-non-default-zone-explained.aspx
Summary: Always crawl the Default Zone’s URL! DO NOT attempt to crawl any other alternative access mapping URLs.
A customer had a SharePoint 2010 site collection that we upgraded to SharePoint 2013.
The variation pages propagation jobs were set to run every three minutes.
The publish of an existing page in the variation root caused a “Started…Finished” propagation log entry with no information about the child variations:
The publishing of a new page in the variation root showed the “Started…Finished” message, along with the information about the child variation pages:
It turns out that there is a very important hidden property called NotificationMode on the Variation Label page that seems to be set to null during upgrade.
This NotificationMode property needs to:
1. Have a value for Variations to propagate;
2. Be set to true on the item in the list that is the root label;
3. Be set to false on child variations in the list.
Here is the KB article that contains a powershell script to run to fix NotificationMode: http://support.microsoft.com/kb/2925599