When testing role based security, it can be helpful to right click IE and “Run as different user.” The below PowerShell script automates this process to make it easier to launch multiple IE windows for testing. Keeping a copy on Windows 7/8 workstations can help users jump into testing easily and with fewer password typo lockouts. If you find this helpful, please leave a comment.
# Launch multiple IE windows as different test user accounts. Great for testing role based security systems.
# Updated line 3 with user name, line 6 with Active Directory domain, and line 9 with SharePoint URL.
The below PowerShell can be used to email all users of all site collections on your system. I find this helpful when planning maintenance outages to alert users of the down time, impact, and changes being performed.
Scripting this was harder than I thought it should be, so I wanted to share this crazy long PowerShell one liner. If anybody knows of a shorter way, please leave a comment or Tweet me. First, we get the web applications including a special switch to get Central Admin (which is normally skipped for safety). Then we get the site collections, but since help collection has one we need to filter those out. Then we grab the Health Analyzer Rules Definitions list. Finally, we can filter for disabled items and display as a table.
When working on a new farm that someone else installed. Or heck, even one I installed but just can’t remember how. This is a good way to confirm your assumptions about any red or yellow Health warnings you see (or don’t see because they’re suppressed)
I would also recommend creating a new filtered view in the Central Admin GUI for an easy way to quickly view these going forward. There are legitimate times when a rule should be disabled, that’s why we have the checkbox. However, it pays to know what the current settings are and not forget those hidden items.
Once all of the health rules are the way you like, run a quick SPTimerJob refresh to see the outcomes of those rules.
Splitting a large site collection into many can make backups, storage scaling, and even development easier. This is a pattern I like to call the DLSC or "Document Library Site Collection.”
A site collection starts our small at first, gets popular, explodes in size seemingly overnight, and the SharePoint admins scramble to support it. Sound familiar?
It can be helpful to peel out a large Document Library into a dedicated site collection. Then you have more options via PowerShell and SQL to manage backups. Have five document libraries with 100GB each? Fine, split them out to 5 site collections in 5 SQL databases. Very manageable.
How To – Split a Document Library into a new Site Collection
1) Make a new SQL content database (optional). If you know LOTS of content will be coming, then give it room to grow now.
2) Make a new blank site collection. The below PowerShell command can help direct the site creation to a new database. I like to use STS#1 for “Blank Site” because it has a minimal simple footprint. Less is more.
New-SPSitehttp://sharepoint.com/sites/doclib-OwnerAlias“DOMAIN\Admin”-ContentDatabaseWSS_Content_DocLib-Name“Document Library Site Collection”-Description“DLSC”-Template“STS#1″
3) Export the source Document Library to CMP format
Manage two sets of security. Yes, you’ll have to grant people permissions in two places. Even using SPGroups won’t help because those are scoped to one site collection. AD groups can help. Those would be a great way to grant security to many site collections at once. All about scale. With only 2 sites AD groups probably aren’t worth the trouble, but with 20 it sure would help.
Sandbox code solutions. These only run in 1 site collection, so if you’re using them to manage documents and move those document libraries you could see issues. The workaround would probably be to upgrade the code to a Central Admin farm WSP solution.
Dependency. For some migrations you’ll need to copy ALL site collections. If you copy just 1 then you may have broken links or missing dependencies.