Which is usually something like:
Register-SPWorkflowService -SPSite <URL> -WorkflowHostUri 'https://wfhost:12990' -AllowOAuthHttp

But what if you want to hook it up to a 2nd web app?

Well, run basically the same command, but add a ScopeName to the 2nd entry and also use the Force parameter.

Register-SPWorkflowService -SPSite <URL #2> -WorkflowHostUri 'https://wfhost:12990' -AllowOAuthHttp  -ScopeName  <some text here> -Force

You should be able to verify that it took by going to 'https://wfhost:12990/<scopename text used above>

https://technet.microsoft.com/en-us/library/jj663115%28v=office.15%29.aspx

https://technet.microsoft.com/en-us/library/jj658588%28v=office.15%29

The "SharePoint 2013 Workflow" Platform Type was there and it would attempt to open with a "Generating Local Cache" Pop-up box, but would just blank out after that with no empty workflow opened.

Originally, I thought it must be the workstation, but it worked against another SP13 farm in the same network.

After troubleshooting, it took a clearing of the config cache on the SP13 WFEs on that farm to resolve the issue.

Try adding "-confirm:$false" to the end of the command...

For SP13, they decided to combined the two "Shared & Personal" into one "Documents" with a "Shared with Everyone" folder in it. When someone comes to your MySite, they can only see the stuff in the "Shared with Everyone" folder, unless you have changed the permissions for the DocLib.

The script will also write to an file "$outfile" the names of any MySite Site Collections that did not migrate cleanly. This may be due to various reasons, such as the "Documents" DocLib wasn't empty, one of the SP10 DocLibs were missing, etc

This would especially be good to run right after a migration, instead of hoping everyone would select the "One Library is all you need" on the pop-up the first time they go to their MySite in SP13 right after migration.

Modify the "$outfile" variable to where you want the file to be written to.

Also, run this as a system account, unless you want your name plastered throughout everyone's "Modified By" in the "Documents" Doclib and them wondering why you were in there...

---

#run this as a system account

Add-pssnapin Microsoft.SharePoint.PowerShell - ErrorAction SilentlyContinue

$outfile = "c:\move-docs.txt"

$mysites = get-spsite -webapplication "<MySite Web Application>" -limit all
foreach ($site in $mysites){
    $web = get-spweb $site.url
    $result = [Microsoft.SharePoint.Portal.UserProfiles.MySiteDocumentMoveUtility]::FirstRunDocumentMove($web).ToString()
    if ($result -eq "False")
        {"$result $site" | Out-file $outfile -encoding string]
    else
        { [Microsoft.SharePoint.Portal.UserProfiles.MySiteDocumentMoveUtility]::FirstRunDocumentMove($web)}
}

---

#Use this to turn off the MySites First Run Experience

$web = get-SPWeb http://mysiteurl
$web.Properties[“urn:schemas-microsoft-com:sharepoint:portal:profile:SPS-O15FirstRunExperience”]=”OFF” 
$web.Update()

In a "SharePoint 2013 Management Shell...

enable-spfeature "developer" -url "App Store Site Collection URL"

*** you only need to do this to the App Store site collection...

Originally I thought you need to deploy the Developer feature to all site collections, which doesn't seem to be the case after testing it...

But if you do need to deploy a feature to all Site Collections in a Web App, you could use the PS script below... just change the "developer" to the feature name, like "Reporting" or "ShareWithEveryone"

---

Add-PSSnapin Microsoft.SharePoint.PowerShell - erroraction SilentlyContinue

$sites = get-spsite -webapplication "<web application>" -limit all
foreach ($site in $sites) {
    enable-spfeature "developer" -url $site.url
    write-host "enabled sideloading on" $site.url
}

write-host "Completed"

All Users, including Site Collection Admins & Farm Admins, are getting "Sorry, this site hasn't been shared with you" while trying to access any site collection under a web application

Solution:

If you set the Super User & Reader Accounts to a domain account for the Web Application(s) using PowerShell, make sure they have been added to the Web Application(s) via Central Admin with the appropriate rights.

More Information:

By default, the Portal Super User account is the site’s System Account, and the Portal Super Reader account is NT Authority\Local Service.

https://technet.microsoft.com/en-us/library/ff758656.aspx

"This item was partially parsed. The Item has been truncated in the index because it exceeds the maximum size. <Document> was partically processed. The parser was not able to parse the entire document."

Solution:

Use PowerShell to increase the Maximum Download Limit.

• Open the SharePoint Management Shell and run the following commands:
  1. $searchapp = Get-SPEnterpriseSearchServiceApplication
  2. $searchapp.GetProperty(“MaxDownloadSize”) (Shows current size)
  3. $searchapp.SetProperty(“MaxDownloadSize”, <new size>)
  4. $searchapp.Update()
• Restart the server & start a full crawl to make the errors disappear.. unless the document is larger than the new setting.

*The default is set for 64MB...

*While playing with this, I was trying to get it to spew an error at me saying the number was too large.. Even after entering "2050000", it took it. I ended up giving up and going with just doubling the default for now.

If your ULS Viewer is blank while trying to run realtime logs... but you are gettting up to date SP ULS logs under the hive, try moving the current logs from under the logs folder to a safe place to clean out the logs folder... Or you can just delete them...& then re-open the ULS Viewer...

Seems if even one of the logs in that folder is out of wack, it messes up the whole viewing process...

Or if you are willing, you can go for the "Microsoft Certified Solutions Manager (MCSM)" 

MCSE - SharePoint (5 exams)

Step	Title	Optional training	Required exam	Certification earned
1	Installing and Configuring Windows Server 2012	410	410
2	Administering Windows Server 2012	411	411
3	Configuring Advanced Windows Server 2012 Services After successfully completing steps 1-3, you'll earn a Microsoft Certified Solutions Associate (MCSA): Windows Server 2012 certification.	412	412
4	Core Solutions of Microsoft SharePoint Server 2013	331	331
5	Advanced Solutions of Microsoft SharePoint Server 2013	332	332

MCSD: SharePoint 2013 Applications (4 exams)

Step	Title	Optional training	Required exam	Certification earned
1	Programming in HTML5 with JavaScript and CSS3	480	480
2	Developing ASP.NET MVC 4 Web Applications	486	486
3	Developing Microsoft SharePoint Server 2013 Core Solutions	488	488
4	Developing Microsoft SharePoint Server 2013 Advanced Solutions	489	489

MCSM: SharePoint 2013 (9 exams)

Step	Title	Optional training	Required exam	Certification earned
1	Installing and Configuring Windows Server 2012	410	410
2	Administering Windows Server 2012	411	411
3	Configuring Advanced Windows Server 2012 Services After successfully completing steps 1-3, you'll earn a Microsoft Certified Solutions Associate (MCSA): Windows Server 2012 certification.	412	412
4	Core Solutions of Microsoft SharePoint Server 2013	331	331
5	Advanced Solutions of Microsoft SharePoint Server 2013	332	332
6	Developing Microsoft SharePoint Server 2013 Core Solutions	Not yet available	488
7	Developing Microsoft SharePoint Server 2013 Advanced Solutions	Not yet available	489
8	MCSM SharePoint Knowledge Exam	Register*	943**
9	MCSM SharePoint Lab Exam	Register*	944***

* Effective July 1, 2013, training for the knowledge and lab exams is no longer required.

** Register for exam 943 at Prometric.

*** Register for the lab exam at the Advanced Certification Learning Portal.

Links: https://www.microsoft.com/learning/en-us/sharepoint-certification.aspx

On some farms it would work great and other very similar farms, it would error out...

After doing some research online, they were getting the famous "The server could not complete your request" with the blank Details pane when trying to copy an OOTB workflow...

Running a Fiddler 2 trace while trying to copy the workflow via SharePoint Designer showed that URLs ending in  ".rules" & ".xoml" were being blocked.

Looking at IIS 7.5 under Request Filtering, both ".rules" & ".xoml" were set to false under enabled.

After I deleted both entries, I was able to copy the OOTB workflows at a subsite level.

You would also need to re-add them via "Allow File Name Extension" in the Request Filtering area, if you have "Allow unlisted file name extensions" unchecked.