MOSS-Exchange

I installed KB4482464 on my sandbox server without issue so I moved to my development farm. Following the patch, Central Admin (CA) had an error: Unknown server tag 'AdminControls:MigrationToolPromotionTip'. I noticed that the sandbox environment CA had this banner: You can now use the SharePoint Migration Tool to migrate to OneDrive and SharePoint Online. It looks like that failed in the Dev farm. The Configuration Wizard GUI failed to successfully run. Solution: I ran PSCONFIG with these options on my primary APP server: psconfig.exe -cmd helpcollections -installall -cmd secureresources -cmd services -install -cmd installfeatures -cmd applicationcontent -install -cmd upgrade -inplace b2b -force -wait I ran PSCONFIG with these options on my remaining app, search and WFE servers: psconfig.exe -cmd upgrade -inplace b2b -wait -force I will exclude this update from my deployment on SCCM and run it manually.

We had a use case of an InfoPath form with two person or group columns among other details. The list owner wanted to get the email address auto-populated in corresponding columns not on the form. I created two new person or group columns but changed the "Show field" to "Work email" as shown below: Then I created a SharePoint Designer workflow to set field in current item to the value of the corresponding person or group field from the InfoPath form. I set the workflow to start on submission. It worked just fine. 

Copying to an Office 365 Site Collection requires Custom Scripts to be enabled at the destination Using the Sharegate Desktop to Migrate on-premise team sites to Office 365 failed with Custom Scripts error I was able to resolve this with the following script: asnp *office* $adminUPN="Admin@orgname.onmicrosoft.com" $orgName="OrgName" $userCredential = Get-Credential -UserName $adminUPN -Message "Type the password." Connect-SPOService -Url https://$orgName-admin.sharepoint.com -Credential $userCredential $sites = Get-SPOSite -Limit all foreach ($site in $sites) { Set-SPOSite $site -DenyAddAndCustomizePages 0 } Please make sure you understand the security implications of this change. In my case, I was able to re-enable custom scripts on most of the sites following the migration without errors. Prerequisite is the SharePoint Online Management Shell

I needed to edit a SharePoint 2013 page to open links from a Links app webpart in a new tab as the links were used for reference for the form on the page. Users were clicking the links and losing their progress in the form fields. We weren't able to reliably explain "right-click to open in new tab." I found a SharePoint designer solution which explained modifying the XSLT. I didn't want to attempt it. JQuery should be able to do this for you.  I put a script editor web part on the page I downloaded the JQuery into the Site Assets app I put the following snippet into the script editor webpart <script type="text/javascript" src="/sites/sitename/SiteAssets/scripts/jquery-3.4.1.min.js"> </script> <script> $(document).ready(function(){   $('a.ms-draggable').click(function(){     window.open(this.href);     return false;   }); }); </script> the a.ms-draggable was key to this so it didn't

I had a group complaining that users were receiving errors and unable to submit responses to a survey. I was able to trace the corelation id to this error in the ULS logs: System.IndexOutOfRangeException: Index was outside the bounds of the array.  at Microsoft.SharePoint.WebControls.RatingScaleField.Focus()    The root cause was the question was malformed. Scale questions are very misleading. You put a name or header in the Question and Type box then the actual question in the "sub-question" box. Once I put the question in the sub-question box and saved it, all users were able to complete the survey. See screen shot for an example.

Using CommVault Simpana item level SharePoint backup, one site collection was failing with Exception of type 'Cobalt.ErrorException' was thrown. We exported the document library using Central Admin under Backup and Restore==>Granular Backup==>Export a site or list. This produced logs where we experienced the same error.  We were able to pin it down to a checked out document. I was able to run a process to check in all checked out documents as major versions (there were four more). Re-ran the export without any errors. Subsequent backups are successful as well. Typically our backup solutions work fine with checked out documents. This site was recently migrated to this farm so maybe there was some difference in how the export function saw the checked out documents.