Missing Server Side Dependencies – 8d6034c4-a416-e535-281a-6b714894e1aa
So what is this you ask? Well, I did a little digging, I watched the Timer Job and the query it sent ( to the content database of the central admin site):
SELECT tp_WebPartTypeId, COUNT(1), tp_Assembly, tp_Class
FROM AllWebParts (NOLOCK)
WHERE tp_WebPartTypeId IS NOT NULL GROUP BY tp_WebPartTypeId, tp_Assembly, tp_Class
You get back a result set that has a null for the tp_Assembly column for the web part. What is this web part you ask, well it is the Microsoft.Office.Server.Search.WebControls.SearchTopologyView web part in the Microsoft.Office.Server.Search, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c assembly.
If you do a query to see where these 6 instance are:
where tp_WebPartTypeId = ‘8D6034C4-A416-E535-281A-6B714894E1AA’
You will see that the web part exists on two pages:
Open those pages, notice…It DOES exist!
Now, here is the funny thing – rerun the queries. As soon as you open those pages, the databsae gets updated and the error will go away. Weird!!!
Not a bug, but never knew this,…
if you have a SharePoint based site that is configured to recycle the application pool it depends on everynight (the default behaviour), the first site access for that app pool will have a 30-120 second delay on it (or more).
This isn’t a “bug” as its simply compiling, caching, etc… on the server after the recycle (or iisreset).
Manual recycles/resets can’t be resolved – however there is a way to “wake up” the site every night after the daily recycle has happened.
is a little exe that basically “opens” the sites for the first time – it basically becomes the “first user” that suffers the delay. After that, loading times will be rediculously fast 🙂 – schedule this to run each night @ 4/5am and voila – fast intranet at 9am 😛