Latest file in a directory with subfolders

Very often we need to find the latest/most recent files in a folder. You can use the below script to copy the files into a directory. This will only copy the latest file to the directory.

get-childitem $sourceDir | where {(!$_.PSIsContainer) -and ($_.FullName -like '*.filetype*') } | sort-object lastwritetime | foreach {Copy-Item -Path $_.FullName $_.DestDir  -Force }

Error with timer job, deploying solutions and get-sptrustedtokenissuer

Note: Below recommendation should never be tried in a production environment. Completely unsupported by Microsoft.

My colleague recently ran into an issue with deploying solutions and running Powershell commands related to Trusted token issuer...The error message was very cryptic, "Invalid URI: The URI is empty".

Below is how the Powershell command looked like:



We googled and found lot of articles related to timer job and clearing cache by going into C:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config\ folder. But none of suggestions worked. Looking at the logs, we found the below:

The SPPersistedObject with Name CustomSTS, Id b98a7f69-5c38-46dd-9be8-4f8aaced5233,
Parent 3e0eff9b-340a-46ce-95ca-6142cea8fe4f failed to initialize with the following error:
System.UriFormatException: Invalid URI: The URI is empty.   
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.DeserializeBasicObject(XmlElement xmlValue, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlNodeList childNodes, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlDocument value, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPPersistedObject.Initialize(ISPPersistedStoreProvider persistedStoreProvider, Guid id, Guid parentId, String name, SPObjectStatus status, Int64 version, XmlDocument state)

System.UriFormatException: Invalid URI: The URI is empty.    
at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.DeserializeBasicObject(XmlElement xmlValue, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlNodeList childNodes, Boolean isMerge, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPAutoSerializingObject.SetStateXml(XmlDocument value, Boolean bResolveMissingTypes)    
at Microsoft.SharePoint.Administration.SPPersistedObject.Initialize(ISPPersistedStoreProvider persistedStoreProvider, Guid id, Guid parentId, String name, SPObjectStatus status, Int64 version, XmlDocument state)    
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.GetObject(Guid id, Guid parentId, Guid type, String name, SPObjectStatus status, Byte[] versionBuffer, String xml)    
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.FetchObject(Guid id)   
at Microsoft.SharePoint.Administration.SPConfigurationDatabase.GetObject(Guid id, Boolean checkInMemoryCache, Boolean checkFileSystemCache)   
at  Microsoft.SharePoint.Administration.SPConfigurationDatabase.Microsoft.SharePoint.Administration.ISPPersistedStoreProvider.GetObject(Guid id)    
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.get_Item(Guid objId)    
at Microsoft.SharePoint.Administration.SPPersistedObjectCollection`1.d__0.MoveNext()    
at Microsoft.SharePoint.PowerShell.SPCmdletGetSPIdentityProvider.RetrieveDataObjects()   
 at Microsoft.SharePoint.PowerShell.SPGetCmdletBase`1.InternalProcessRecord()    
at Microsoft.SharePoint.PowerShell.SPCmdlet.ProcessRecord()   


Just before we decided to rebuild the farm, I decided to look at the SharePoint Configuration database as last resort (again strictly not recommended for production database)


I ran the below query:

SELECT [Id]
      ,[ClassId]
      ,[ParentId]
      ,[Name]
      ,[Status]
      ,[Version]
      ,[Properties]
  FROM [dbo].[Objects]
  where properties like '%CustomSTS%'
GO

Replace CustomSTS in the query with whatever you think is appropriate. Sometimes you might not see any rows come back. You will need to re-start your research at this point.

I backed up the database and deleted the entries from the above output. Went back to powershell and ran the command again. Voila ! It ran perfectly with no issues. Same with deployment of wsp files.

Thanks to my colleague who let me debug this for him. His machine will be rebuilt soon as it was completely hosed before this.

Hope you never need to do this !

SharePoint 2013 Search Error

Yesterday, I got a request to check on one our SharePoint 2013 applications which has not been modified in last couple of months. The users were getting an error related to search...

Search has encountered a problem that prevents results from being returned. If the issue persists, please contact your administrator.

Correlation ID: 85a0bd9c-3615-f0f4-b26f-38cd545f34eb

Below are the debugging steps for such an error message:

1) Looked up the correlation id in ULS logs and found an error related to query processing
Saw an error related toaccess denied for the crawler account ( I knew this was not correct because we did not update or change any security related to this account)
2) Looked up event viewer for any error messages and the below showed up
w3wp.exe: All query processing components are in 'Failed' status.
w3wp.exe: Query processing component 'net.tcp://nameoftheserver/D30C5C/QueryProcessingComponent1/ImsQueryInternal' changes its status to 'Failed'.
3) Checked Central admin -> Service applications - > Search Service application for status on search components
4) Notice an yellow exclamation mark next to query processing
5) Restarted SharePoint Administration, SharePoint Timer Service and SharePoint Administration services through services mmc
6) Went back to Central administration to see if the exclamation mark was gone. Nope. Was still there.
7) Went back to services and restarted the Search Host Controller service
8) Opened command prompt and ran the below commands
net stop osearch15
net start osearch15
9) Went back to Central admin and refreshed the search application page
10) Saw exclamation marks on all Search related components - did not feel good at this point
11) Refreshed the page and saw that each of the components were turning green now - felt better at this point
12) After few minutes all components were in green - felt really good at this point
13) Went to the actual site and performed a search - results came back and problem solved


If you see error messages related to search, do not reset the index or re-provision the search application. Sometimes a simple reboot might actually fix the problem.

Hope this helps you !