As much as anything, this is a reminder for me. We had a customer who were trying to run a PowerShell script that, ultimately, relied on an assembly that was contained in a WSP we’d written. The script wouldn’t work, however, and it transpired that the WSP had not been deployed to the server that they were running the script on. Continue reading “WSP Not Deployed to a SharePoint App Server”
So, I’ve somehow managed to get through most of the SP2010 cycle without having to use the Enterprise Content Type hub – until last week. This was my opportunity to stumble across one of the gotchas of the ECT hub – it doesn’t work with blank sites. We had a number of site collections based on the Blank site template, and content types would not replicated to it. Other site collections based on other templates – such as Team sites – worked fine.
Interesting. And this tickled a neuron. Continue reading “Content Type Hubs and the Blank Site Template – Fixing them”
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.
Last week I was working on a customer’s Dev system and when we tried to set up search we received the error:
“The search service is not able to connect to the machine that hosts the administration component”
Interesting. And annoying. I tried removing and recreating the search application service – and we got the same error. Weirdly, it had been working previously. Continue reading
SharePoint lists have the ability to export their contents to an Excel Workbook.
This is quite cute – it gives the users a way to get the data out into something they’re familiar with, can manipulate and can print. However, I was having an issue. Using a list based on a Custom List (above), one of my columns (Enquiry) wasn’t exported:
I wondered at first if this was because of it’s column type (Hyperlink), or because I’d created the column programmatically. Then, on a hunch really, I tried changing the column order. I added another column before it in the list view. I used the ID column, but any should work. When I exported the list – all the columns I wanted came through (but the ID column didn’t).
What I think is going on here is that if you used the same export on a document library then typically – though not always – the first column is an icon for the type of file it is. My suspicion is that some muppet, when writing the export to excel, realised that they’d have these icons, and decided to avoid them by excluding the first column. This is unfortunate for two reasons:
- Not all lists have icons – witness my Custom List
- Not all document libraries have the file icon as the first column.
For now the resolution would be to have another column as the first on your list.
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.
One of our customers had a penetration test performed on their SharePoint system. I think it’s fairly standard, but it could have a custom login form. In fact, given some of the errors, I think it must have been – but I had little involvement, so I’m not sure. Heck, it could even have been a SharePoint 2007 system, or a new login form that we didn’t write.
Either way, I thought it would be interesting (and a good reminder) to look at some of the issues it threw up… Continue reading “Results of Penetration Test on SharePoint system”