I “registered” a SLES box with an OES2 key, however I only have SLES update repositories from doing this, not the OES2 ones.
Fix is the same as it was in SP1;
Fab article to help troubleshoot those “client running slow” issues
though in 99% of the time, it’s either;
1) Users in Online mode (High RPC request latency/queue length)
2) Lack of disk spindles / IOPS for DB/Log drives (disk queue length will determine this)
3) Users in Online mode 😉
Important one here;
|Multiple roles (combinations of Hub Transport, Client Access, and Mailbox server roles)||10 GB||10 GB plus 3-30 MB per mailbox (4 core server)
14 GB plus 3-30 MB per mailbox (8 core server)
18 GB plus 3-30 MB per mailbox (12 core server)
22 GB plus 3-30 MB per mailbox (16 core server)
30 GB plus 3-30 MB per mailbox (24 core server)
This is variable based on the user profile. For more details, see “Mailbox Server Role” later in this topic.
Also it is not supported on vSphere4, you require Update 1 for it to be supported from MS.
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 😛
There is a known bug in OCS 2007 R2 (and I presume 2007) whilst using the Remote Screen feature.
If you try to run an elevated process under Vista/Windows 7 and have UAC enabled the Accept box for UAC (the Yes/No prompt) is ran in the “Secure Desktop” and therefore inaccessible to the user.
This is also the case if it prompts for a username/password.
From what I can see the only way around this is to DISABLE UAC – not recommended obviously.