For finding files in unix from a particular folder i'd often use: find . -name *.jpg (or similar). Today I had the same need on windows. I needed to copy all files (images) from a rootfolder (and all files withing the subfolders) to another folder. The following lines will help you along to do just that (just add a copy for each of the files).

$items = Get-ChildItem -Recurse "C:\SomeDirectory\"
$filesWithDirectory = $items|?{$_.extension -eq ".jpg"}|select Directory,Name 

This will give you a table with the following syntax (so you can use it in a foreach loop to copy or to whatever):

Directory              Name
c:\somedir\blabla\     somepicture.jpg 

Enjoy!

Any comments / ideas you'd like to share with me for such a post?

I scanned the event logs; none giving any useful information, all seemed to be working.

The only two errors if relevance were:

• [Microsoft.Office.Server.Search.Query.SearchServiceNotFoundException]: The search request was unable to connect to the Search Service.
• [Microsoft.Office.Server.Search.Administration.SearchServiceApplicationFault]: The creator of this fault did not specify a Reason

I did a "nctrl status" on the fast-backends and admin, all services was running. Why all of the sudden did the query service stop working?
It turns out that the server-clocks were different (not synchronized). I adjusted the date & time (one server was 8 minutes behind the other) and it started working automagically!

I'm guessing WCF times out behind the scenes or some communication error occurs silently because of this. But no useful info in any logs. Quite frustrating!

So, lesson learnt: Check the system time on ALL Servers! They should be the same.
I hope this will be useful for others with the same problem(as google provides no results for this behaviour).

Take a look at this post: http://blogs.msdn.com/b/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx and look at the Dynamic Cache Manager service (can be downloaded and installed from http://www.microsoft.com/downloads/details.aspx?FamilyID=e24ade0a-5efe-43c8-b9c3-5d0ecb2f39af )

I've installed it on most server and after tweaking the params, the server load falls down to normal. Quite neat and a really annoying bug if you don't know where to look.

From Powershell list the external content types (ECTS) / LOB (Line of Business) from the BCS/BDC (catalog meta data) service.

This is useful if you're scripting e.g. like we are adding of content-sources using the BDC models created. Here it is:

$ctx = "http://localhost"
# Get the BDC context
$bdc = Get-SPBusinessDataCatalogMetaDataObject -BdcObjectType Catalog -ServiceContext $ctx
# Get the list of all LOB systems
$lobs = $bdc.GetLobSystems("*")
Foreach($lob in $lobs){
$lobId = $lob.Id
$lobName = $lob.Name
$lobDisplayName = $lob.DefaultDisplayName
$lobEntities = $lob.Entities
$lobSystemInstance = $lob.SystemInstances
Write-Host $lob.DefaultDisplayName
}

"Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator. Correlation ID: e5f9698d-23e3-4926-9fdd-63f17073f3ec."

After spending a couple of hours trying to figure out what went wrong (Cause no logging showed anything useful), it turns out that the ECT field and properties is still stuck for the old version. I tried deleting the old versions before redeploying. No luck, the old fields where still there.

Finally, we figured out what to do: It looks like the ECT is stuck in the Application Service Proxy aswell, and when redeployed / removed, this is not updated. Solution: Log in to Central Admin - Goto BDC application proxy, remove the ECTS and redeploy !:D Voila! You would have to recreate the external lists though. But it works.

You might recognize an error like "The local farm is not accessible. Cmdlets with FeatureDependecy are not registered".

Luckily, it's fairly easy to solve this problem (Please don't do this on a production server, or minimize the access needed);

• Log onto your sql-server
• Goto security
• Add the user you're having trouble with
• Under "user mapping" ; select the Sharpoint_Config
• Add the Roles: db_owner and Sharepoint_Shell_Access
• Press OK.
• Re-open Powershell using the troublesome user and it should work!

Here's the first version of the solution deployer. It consists of a powershell script (that must be run in order to be able to deploy solutions from the web), a webpart for deploying /updating/removing the solutions and some custom code doing all the work.

I created a webpart listing all solutions (with a configurable path / dir to scan for solutions) with the different commands. Forgive me for the GUI, I couldn't care less for the GUI for this utility ;)

Note: When the deploy / Remove is clicked a job is created which will start the deploy / removal job ASAP. This will do a IISReset making the site unavailable for a while.

This code comes with no warranty, nor have the update method been tested extensively. There will be improvements to the code and the webpart will be made more configurable (e.g removing hardcoded paths etc.).

This can easily be automated by making visual studio build the solutions to a remotely shared folder on the server, then the webpart will pick up the WSP-files and the developers can then update them from the interface itself.

The files are attached to this post.