So, related to my previous post, we had problems initially deleting the Search Service Application. The Search Content Application’s Database had become ‘Suspect’. I’ve had this happen a few times before (I’m not sure why – I ain’t a DB Admin) and I have a little script that I run that seems to fix this, mostly.
EXEC sp_resetstatus 'PROBLEM_DB_NAME'
ALTER DATABASE PROBLEM_DB_NAME SET EMERGENCY
ALTER DATABASE PROBLEM_DB_NAME SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ('PROBLEM_DB_NAME', REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE PROBLEM_DB_NAME SET MULTI_USER
No, I’m not entirely sure of the logic of how it works, and I’m pretty sure I can here DB Admins across the world screaming, but for my dev systems that I can afford to trash, it seems adequate.
Anyway, on this occasion it didn’t work, so I decided to simply delete the Search Service Application. I tried this through the UI – but it just seemed to hang. I tried again – and it seemed to hang. It wasn’t going away. I tried PowerShell – which took me a while as I’m still a fan of STSADM – and that didn’t work.
In the end I found the solution – on Donal Conlon’s blog – use STSADM -o deleteconfigurationobject
Yes, there’s a certain irony in that.
I have a development machine that I was creating a number of sites within. I wanted to create about 10,000 sites or so (and have done more than that in testing before without a problem). When I started the process that was creating these running on my machine it was taking about 20 seconds per site. After a mere 2000 sites, it was then talking 30 minutes per site. Something isn’t right.
I did a bit of digging and found that others have had the same problem – but no solution.
I then spoke to one of our administrators, and he suggest clearing out the ‘event cache’ table. I’d never heard of that (and I’ve no idea how he found out about it), but his advice was:
Minimise the amount of rows in the EventCache SQL table:
- set ChangeLogRetentionPeriod to 1 day (1.00:00:00) on web application
- set EventLogRetentionPeriod to 1 day (1.00:00:00) on web application
- set ‘Change Log’ timer job to run daily (default is weekly)
Okay, so I did this using STSADM:
stsadm -o setproperty -pn change-log-retention-period -pv 1
stsadm -o setproperty -pn event-log-retention-period -pv 1
…and I then changed the Change Log timer job’ schedule in central admin, and set it running right away.
The timer job took about 8 minutes to run. That was a surprisingly long time.
When I then tried creating a site, it took 7 minutes. Clearly, this is still an unwell system, but that’s a lot better than 30 minutes. I’ll update if I find more.
I’ve recently come to the conclusion that I’m unlikely to use Themes in SharePoint again in a hurry. Why?
- Themes allow you to provide a bunch of CSS styles. So does the AlternateCssURL.
- Themes have to be applied site-by-site (unless you do some programming, or extend STSADM). Alternate CSS or Master Pages can be changed for a site and subsites, for a Publishing site anyway (although with some limitations).
- Alternate CSS can be provisioned from a single URL – so benefiting from browser caching just like images.
- The Alternate CSS can style the DatePicker. Themes can’t.
- The Alternate CSS can style Application Pages, just like Themes (but unlike Master Pages).
- No problems with ‘Style Merging’ when the Theme is provisioned.
- Style can be updated in one location.
- Themes can be changed through the UI for any site. Only Publishing sites have a user interface for changing the Alternate CSS.
Yes, many of the same distinctions between Master Pages and Themes still exist, and the same sort of analysis and choice of approach should be done. However, it means that we can kind of ignore Master Pages, and just focus on Alternate CSS vs Themes – and it seems to me that apart from the last point above, the Alternate CSS approach seems to equal or better than Themes.
Regarding the last point, well, to apply my theme I’d set the Alternate CSS in a Feature Receiver. This is okay, though, as I’d probably be writing one anyway to apply the correct master page to different types of site.
So, the answer I’ve come to now – I’d use the _layouts directory – create a sub-directory for your brand, and put your CSS and images in there.
I’d built a .wsp (Web Solutions Package) for a customer, containing the branding I’ve been working on. However, when they tried the command:
stsadm -o addsolution -filename branding.wsp
they got the error:
Object reference not set to an instance of an object. c:branding.wsp: The Solution installation failed.
Interesting – works on my machine. They were running the command as the ‘Administrator’ user on the SharePoint system. A bit of digging, though, showed that the problem was due to either:
- Not running under a Farm Admin account (which I understand the ‘Administrator’ user was)
- Not having rights to the Central Admin Content Database on SQL server.
Well, we tried running the STSADM command as the service account, and that appeared to work. ‘Course, this is all over the phone so I’m not certain what permissions that account has, but it appeared to run.