SharePoint Online: News from associated sites are not displayed in the hub News Webpart
Summary I recently worked on a case where News from associated sites are not displayed in the hub News Webpart. This took several months to resolve due to the complexity of hub news webpart and how it integrates with the Search Engine to retrieve and display news from the associated sites. Before getting into the problem, just providing a quick example of the News webpart configuration with a Hub Site. Hub Site Example: The following image shows a Hub site named “hubsite” and 2 associated sites (“hubsitechild1” and hubsitechild2”) Posting News items from the Hub: This is what the News Webpart looks like from the root Hub Site: Now let’s look at a child site: By default, the News Webpart will only show news from the current site: Site Admins will need to change this Webpart to view news from the Hub or any associated Hub site. In this example I will choose the “Hubsite”. With this configuration “Hubsitechild1” will display News posts from the Hub site Note: Since the retrieval of the new posts are based on search, you will not see new posts show up in the news webpart for about 5-15 minutes. How does it work? The News Webpart triggers a request to the SP Home Microservice with “DepartmentID” Example: https://sphome_base_url/api/v1/news/hub/filtered?departmentId=47060b5d-eb3a-4f7b-a1c0-421fc86cd0f6&start=0&count=13 Note: The DepartmentID will be the Site ID of the root hub site. The SP Home Micrososervice then calls the Search service with “ContentTypeId”, “PromotedState”, “DepartmentId” to retrieve the News items. Example: GET: https://tenant.sharepoint.com/search/_api/search/query?querytext='(*)'&QueryTemplate='PromotedState:2 AND ContentTypeId:0x0101009D1CB255DA76424F860D91F20E6C4118* AND (DepartmentId:47060b5d-eb3a-4f7b-a1c0-421fc86cd0f6 OR DepartmentId:{47060b5d-eb3a-4f7b-a1c0-421fc86cd0f6})'&Properties='ClientFunction:HubNewsArticles ,EnableDynamicGroups:True'&ClientType='SPHomePagesWeb'&SelectProperties='DocID,Path,DocID,SiteID,NormSiteId,WebID,NormWebId,GroupID,Title,Description,PictureThumbnailURL,AuthorOWSUSER,SiteTitle,SPSiteUrl,SiteLogo,PromotedState,FirstPublishedDate,UniqueId,ViewCountLifetime,SiteTemplate,IsExternalContent,SPWebUrl,ContentTypeId,Language,Color,ListItemID,DepartmentId'&SourceId='8413cd39-2156-4e00-b54d-11efd9abdb89'&Sortlist='FirstPublishedDate:1'&BypassResultTypes=true&TrimDuplicates=true&EnableQueryRules=false&EnableSorting=true&StartRow=0&RowLimit=13 The Search results are sent back to the News Webpart and displayed as configured. However, in the case that I was working, the Webpart was not displaying any news, even though the Search request was correct. Cause We found that the default Search Schema had been modified either manually or by a 3 rd party product. In this case the managed property “ AuthorOWSUSER” is used to locate News items. If the value of this property is unexpected or NULL, Hub News items will not be displayed within the Webpart. Here is the default setting for the “AuthorOWSUSER “managed property. As you can see there are 2 crawled properties by default. ows_q_USER__AuthorByline ows_q_USER_Author If either one of these crawled properties are missing, Hub News will not be displayed. Also, we found that in some cases there is a new managed property that uses “AuthorOWSUSER” as an alias. Resolution To resolve this issue, simply fix the modified search schema, which can be modified at the tenant level or the site collection level . The AuthorOWSUSER property exists at both tenant level and site level. How do we reach tenant level settings? Copy this URL and open in the new tab where tenant admin is already signed in https://admin.microsoft.com/sharepoint?page=classicfeatures&modern=true. Under Search, select Open. Select Manage Search Schema on the search administration page. How do we reach site level settings? On one of your affected hub sites, select Settings, and then select Site Settings. If you don't see Site settings, select Site information, and then select View all site settings. Under Site Collection Administration, select Search Schema. At this point your URL should look like this https://TENANT-NAME.sharepoint.com/sites/Hub-SITE-NAME/_layouts/15/listmanagedproperties.aspx?level=sitecol After opening the managed properties list at the tenant/hub site level: 1. Search for “AuthorOWSUSER” 2. You see all matches, including any custom managed properties that set AuthorOWSUSER as an alias. 3. Locate the problematic Managed property and correct the issue by deleting the property or changing the alias. In this example, I will change the alias of “Thiswillbreaknews”. 4. Make sure AuthorOWSUSER is mapped to “ows_q_USER__AuthorByline” and “ows_q_USER_Author”, if the mapping is incorrect, fix it. Please Note: Since these some of these properties are used in real-time, the problem should be resolved almost immediately. In a worst-case scenario, you will have to re-index the site , wait for Search to complete (about 15 minutes), then re-create the News Webpart. Steps to Re-index the site: On the hub site site, select Settings and then select Site settings. If you don't see Site settings, select Site information, and then select View all site settings. Under Search, click Search and offline availability. In the Reindex site section, click Reindex site. More Information For additional reading on the topics discussed in this blog see the following articles. What is a SharePoint hub site? Create a hub site in SharePoint Use the News web part on a SharePoint page Manage the search schema in SharePoint Online Manually request crawling and re-indexing of a site, a library or a listScript to copy specified IIS logs from multiple Servers
Summary Need to copy a set of IIS logs from multiple servers for data analysis? Are you doing it manually? If so, please check out this script as it will help expedite the process. The Script: #Modify Inputs # Host and Drive to store the IISLogs $Hostdir = "\\HOSTSERVER\c$" # Actual Location of the IIS Logs on the Server $iislogsfolder = "c$\inetpub\logs\LogFiles\W3SVC1892304237" #A wild card parameter to determine a file range $thefiles = "*ex1906*" # Create a target folder on host if does not exist $TARGETROOT = "$Hostdir\logs" if(!(Test-Path -Path $TARGETROOT)){ New-Item -ItemType directory -Path $TARGETROOT } # Create an export folder if it does not exist $target = "$Hostdir\logs\export" if(!(Test-Path -Path $target)){ New-Item -ItemType directory -Path $target } #Simple Server list $servers = Get-Content C:\servers.txt # For loop to do the work foreach ($server in $servers) { #make a new folder by server name if it does not exist $TARGETDIR = "$target\$Server" if(!(Test-Path -Path $TARGETDIR)){ New-Item -ItemType directory -Path $TARGETDIR } #Get the files $iislogLogDir = "\\$server\$iislogsfolder" $iislogName = Get-ChildItem "$iislogLogDir" -Recurse -Include "$thefiles" | Get-Item #Start a loop to copy all the files to the host locatiion foreach ($log in $iislogName) { copy-Item -path $log $TARGETDIR } } What the Script Does You only need to modify the inputs and create a server list. Then the script will do the following: Use a list of servers to collect the data from. Create a "logs" folder on the specified drive. Create an "export" sub folder under "logs". Create a sub folder under "export" using server name of each server. Use the wild card file name you specified to target specific files. Copy each targeted file to the correct serer name folder. Notes: If you want to collet 1 file from each server, just specify use the full date name in the search input (ie 190606). You can run this more than once if another file is needed and they will be added to the existing folders. The "export" folder will contain all the files needed. Just compress the folder and your ready to share.Collect SharePoint ULS Logs quicker || Say “No” to Merge-SPLogFile
As a SharePoint Support Engineer, we often need to collect ULS logs from a single server or several servers to help identify our customer's issues. Russ Maxwell has a great blog and script that helps collect ULS on a more "real-time" approach and collects from all servers in the farm from the time you execute the script to the time to terminate that script. ( Jeff shared this out in an email a few weeks back ). We contemplated writing and releasing this, but we wanted to spin the Log Collection process in slightly different direction that we also felt could be useful and more efficient for Admins when "Microsoft" asks them to go grab ULS logs from specific servers. The intent of this script is not to take anything away from Russ' work, just another method to collect ULS logs. I am sure you may be asking, why not just use "Merge-SPLogFile"?SharePoint 2013/2016/2019: How to replace expired WorkFlow Manager Certificates
SharePoint 2013/2016/2019: How to replace expired WorkFlow Manager Certificates Having trouble with your SharePoint 2013-based workflows because your Workflow Manager certificates expired? Here is how you can fix this scenario...SharePoint throws 500 or 403 and remains inaccessible until IISRESET
Summary I have seen this very obscure SharePoint issue a few times and almost impossible to identity and resolve without extensive debugging. So, I just wanted to get this blog out there to help the next SharePoint Admin that may experience this situation with a quick resolution. Symptom: While trying to access the site http://sharepoint users are intermittently presented with 403 and 500 errors and the site remains inaccessible until performing a manual IIS RESET. However, after resetting IIS the site may remain operational for a very short time before the issue reoccurs. When this issue occurs, you will find the following COMException recorded in the ULS Logs. 12/14/2018 14:48:11.11 w3wp.exe (0x22A0) 0x270C SharePoint Foundation Runtime tkau Unexpected System.Runtime.InteropServices.COMException: Cannot complete this action. Please try again. at Microsoft.SharePoint.Library.SPRequestInternalClass.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Int32 iRequestVersion, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, Boolean& pbIsWebWelcomePage, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocid, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) at Microsoft.SharePoint.Library.SPRequest.GetFileAndMetaInfo(String bstrUrl, Byte bPageView, Byte bPageMode, Byte bGetBuildDependencySet, String bstrCurrentFolderUrl, Int32 iRequestVersion, Boolean& pbCanCustomizePages, Boolean& pbCanPersonalizeWebParts, Boolean& pbCanAddDeleteWebParts, Boolean& pbGhostedDocument, Boolean& pbDefaultToPersonal, Boolean& pbIsWebWelcomePage, String& pbstrSiteRoot, Guid& pgSiteId, UInt32& pdwVersion, String& pbstrTimeLastModified, String& pbstrContent, Byte& pVerGhostedSetupPath, UInt32& pdwPartCount, Object& pvarMetaData, Object& pvarMultipleMeetingDoclibRootFolders, String& pbstrRedirectUrl, Boolean& pbObjectIsList, Guid& pgListId, UInt32& pdwItemId, Int64& pllListFlags, Boolean& pbAccessDenied, Guid& pgDocid, Byte& piLevel, UInt64& ppermMask, Object& pvarBuildDependencySet, UInt32& pdwNumBuildDependencies, Object& pvarBuildDependencies, String& pbstrFolderUrl, String& pbstrContentTypeOrder) Cause: This issue is caused by an excessive amount of AD / SharePoint groups or user permissions being added to site collections, list & libraries or pages, which fully consumes the maximum allowed “in-memory security cache” (owssvr!VsecCacheManager) which is 2mb by default. Once this memory has been exceeded, SharePoint is unable to verify user security and responds with a 500/403 error for all users at the server level. Resolution: To resolve this problem, increase the “SecurityCacheMemoryAllowed” setting from the default of 2MB to 20MB. Registry DISCLAIMER: Modifying REGISTRY settings incorrectly can cause serious problems that may prevent your computer from booting properly. Microsoft cannot guarantee that any problems resulting from the configuring of REGISTRY settings can be solved. Modifications of these settings are at your own risk. Steps: Click Start, click Run, type regedit, and then click OK In Registry Editor, locate and then click the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14.0 Right-click 14.0, point to New, and then click Key Note: If you are using SharePoint 2013 the key will be under 15.0 and 16.0 with SharePoint 2016. Type SecurityCacheOptions, and then press ENTER Right-click SecurityCacheOptions, point to New, and then click DWORD value Type SecurityCacheMemoryAllowed, and then press ENTER Right-click SecurityCacheMemoryAllowed, and then click Modify In the Value data box, change the Base to decimal, type the value 20, and then click OK Execute an IISRESET and manually restart the “IIS Administration service”
