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
This issue has caught me out several times – but if you’re using Excel on the SharePoint server – which is common during development – you need to turn off the protected views in the ‘Trust Center’ settings of Excel:
I’ve been set straight on this issue at least twice thanks to this post by JOPX. Unless those protected views are turned off then if you download the file you will only be told the file is corrupt - even if you can download the file and open it without any problem.
Recently, a few of our customer’s systems that I’ve looked at have had the Publishing Infrastucture site collection feature activated, but purely for the top navigation. That seemed quite a heavyweight approach to me. Continue reading
For some reason a new web application on my development VM always returns a 503 Service Unavailable when you go to it.
It turns out that this is due to the app pool supporting 32 bit applications! Change the setting in IIS (App Pool > Advanced Settings > Enable 32 Bit applications should be false)
I had a problem that one of our development machines had been configured in a ‘Least Privileges’ configuration – and it was a bit too least. The content app pool could not write to the logs. OWSTimer and WebAnalytics both could, but there was nothing from W3WP for that web app.
Just a reminder to myself…
Well, the solution was to add the app pool account to the ‘Performance Log Users’ group in AD. You find it under BUILTIN. Reset ISS. Voila!
Last year I was working on a system where we were creating a lot of sites. I mean, tens of thousands of sites, and all within one site collection (they’d all have a few documents and tasks, but not many). Anyway, we were told by a partner’s developer that:
- A Site Collection’s Root Site could only have 127 subsites before performance issues would start
- Each of those subsites could have up to 2000 subsites before performance issues would start
This seemed a bit suspicious to me. I had read on MSDN about the capacity boundaries and limits, and knew about the 2000 subsites per site note:
2,000 per site view
The interface for enumerating subsites of a given Web site does not perform well as the number of subsites surpasses 2,000. Similarly, the All Site Content page and the Tree View Control performance will decrease significantly as the number of subsites grows.
Okay, that’s fine. And I knew that the limit on the number of Sites per Site Collection is 250,000. But I couldn’t find anything about this ’127′ subsites under the root site thing, and I couldn’t help but wonder if this was where the ’127′ value had come from (125 x 2000 = 250,000) as I simply didn’t see why a root site should be any different to any other type of site. Thus, I decided to test it. Continue reading
When you save a Site Template in SharePoint you can specify a Description. That’s fine – but doesn’t really seem to be used anywhere, other than a little note on the ‘Create new Site’ form (see below). I’d always assumed that it was. Well, I was wrong. Continue reading
I’d a really, really weird problem with a customer yesterday. We’d set up their SharePoint search. Indexing seemed to be working correctly, and when I logged in as an administrator, I was getting search results correctly. However, logged in as a normal – though very highly privileged – user my search results were missing! This was some thing of a surprise. It felt like security trimming, but the user was a Site Collection admin, and had Full Control throughout the entire main content web application. Also, we were indexing content off the network file share, and we knew he could access both the SharePoint Content.
However, when he ran a search, he didn’t get any search results. That sucked. I tried another user account – and had the same problem.
Eventually, I looked in the logs and found the following message:
AuthzInitializeContextFromSid failed with ERROR_ACCESS_DENIED. This error indicates that the account under which this process is executing may not have read access to the tokenGroupsGlobalAndUniversal attribute on the querying user’s Active Directory object. Query results which require non-Claims Windows authorization will not be returned to this querying user.