I’ve recently been working with a customer migrating some content from one SharePoint Online Site Collection to another. They have a lot of content, so automating the migrations with PowerShell was really the only we’d be able to get all of their content migrated before we died of old age. Part of what they wanted migrated over was the custom views they had in their Document Libraries. A couple of extra columns here, a grouping there, nothing too complicated. I fired up PowerShell (really VS Code) and started noodling.
Whenever I’m trying something new in PowerShell I have a standard process. I do a Get-Command to see if there’s a cmdlet that does what I need. In this case there were four cmdlets that piqued my interest, Add-PnPView, Get-PnPView, Remove-PnPView, and Set-PnPView. The process seemed super easy, do a Get-PnPView on the source View, gobble up all the details, then spit them back into Add-PnPView on the other site collection. Easy Peasy. Until it isn’t.
Here’s what the view looked like, roughly.
I didn’t do much to it. I added a couple of columns, Created By and File Size and set the view to group by Created By. Pretty standard stuff. Here’s what Get-PnPView told me about said view:
I can see the columns I added in the ViewFields property, but there’s no sign of the grouping anywhere. Knowing what I know about SharePoint I know that information is stored in a Query, but the ViewQuery property is conspicuously empty. What gives? The PnP, in an effort to be efficient, doesn’t download all of the property values for the objects we get. It downloads the schema, and then a subset of the properties that it thinks you’re most likely to use. What’s a fella to do if the thing you need is not in the PnP’s favorite list of properties? You break out one of the PnP’s overlooked gems, Get-PnPProperty.
Not only does Get-PnPProperty get the value of the Property, but it also populates the property in the variable. If you’re getting a collection of objects and need to pull one property for each of them it looks like this:
That hydrates the ViewQuery and ListViewXml property for all of the objects in $viewlist.
It snuck some other properties in too, but I don’t mind.
In this case I was using the View object, but this method is necessary for any PnP object. In the past I’ve had to use it with PnPFile and PnPLists. Sometimes the PnP gives you an error message telling you you need to get the property value, sometimes it’s just empty and you have to know. Either way, it’s worth trying to get the property’s value with Get-PnPProperty.
I was recently dealt a fun task from a customer. They had a site in SharePoint that had a few links in the Quick Launch (left nav, quick nav, whatever) and they wanted to copy the Quick Launch from another site to it. They wanted to keep the existing links below the new ones. Here are some pictures to help it all make sense:
I want to copy these links:
and put them on top of these links on another site.
Of course I immediately thought of your friend and mine, the PnP PowerShell for this task. Sure enough, there are cmdlets for that, Get-PnPNavigationNode and Add-PnPNavigationNode. Just what the doctor ordered.
Add-PnPNavigationNode is pretty basic and I had to work a bit to get exactly what the customer wanted. When you add a Navigtation node with Add-PnPNavigationNode it puts it at the end of the list, which makes sense. You can also throw the switch parameter, –First, to put it at the top. In most situations that probably is fine, but mine was tricky. I didn’t want to put the copied nav nodes at the end, I wanted the existing ones to stay there. I also couldn’t just add them all as –First because then they would end up at the top, but in backwards order. When I get the old nav nodes with Get-PnPNavigationNode it returns them in their correct order, so as I walked through them with Foreach the first one would be added on top, but then the second one, also with the –First switch, would end up on top, and so on. Enter [array]::Reverse.
The Array class in PowerShell has quite a few tricks up its sleeve in the form of operations, and Reverse is one of them. If you want to see the rest, go to this page, or type [array]:: in a PowerShell host and tab through the list. It’s quite impressive.
There’s a lot of foundation there, but you can see where the Array reversal fits in. Here’s how it looked when I ran it:
And here’s what it looked like after I ran it:
There’s a lot more tweaking I can do, like make sure “Home” is still on top, stuff like that, but finding Reverse was an important step in the beginning.
PowerShell does a pretty good job handling dates and times due to its good foundation with .NET and its focus on being cool to use PowerShell users. For basic DateTime formatting the help for Get-Date shows some great, easy to use examples.
help Get-Date –Examples
There’s –Format, –UFormat, and –DisplayHint, and those are all before we get to the flexibility that is .tostring(). There’s a lot of options, sometimes it’s too many options. Sometimes trying to string together exact combination of time and date information I’m looking for is a lot of work. Once again, PowerShell is there for me in the form of .GetDateTimeFormats()
(Get-Date).GetDateTimeFormats()
It lists out a collection of precanned DateTime formats you can select from:
You can use one of those formats just by selecting its index number:
That’s the good news. The bad news is that you have to specify which number you want, and there are 133 formats in the list. If the one that really tickles your fancy is #87 you have to count the lines until you get to it.
Until now.
I had danced this dance a few times, squinting to find that just perfect DateTime format I was looking for and counting the lines leading up to it. Then I put my PowerShell mojo to good use and came up with this little gem:
Another July 1st, another nervous couple of weeks. Fortunately the news this year was good, I was renewed.
Microsoft’s MVP Program is a way that they reward non-Microsoft folks for the contributions they’ve made to the community over the last year. I’ve done enough over the last year to meet that high bar, which is something that I’ve aspired to every year since 2006 when I got my first MVP award.
Being in the MVP Program has been great for me. I have learned so much and made some great lifelong friends. It has been lifechanging.
Congratulations to the other renewed and newly awarded MVPs.
I recently had to do some testing for a customer on a Windows 10 machine whose primary language was not English. I, having lived in the midwest United States my entire life, do not speak any other languages fluently. The customer anticipated this and sent along a very thorough set of directions, complete with pictures, of how to switch the language to English for me. Very kind of them indeed. As I looked through the directions the thought occurred to me, “I’ll probably need to do this a few times. I wonder if I can automate it. I bet I can! PowerShell to the rescue!”
None of it takes place until you log back in, so I added the logoff at the end.
With PowerShell, knowing the answer is good, but knowing how to get the answer is even better. One of my friends, Jeff Hicks, always does a good job explaining the process of find things in PowerShell, so I thought I’d do that here.
I had the steps, in UI form, so I didn’t need to figure that out. There were 4 things that needed to be changed. I just needed to figure out how to make those changes with PowerShell. I went to a PowerShell prompt and typed:
Get-Help language
hoping PowerShell could nudge m in the right direction. I got this back:
It wasn’t exactly what I needed, but it did show me there was a module, International, that was probably a good place to start. And knowing that I needed to change things, I was mostly interested in the Set cmdlets. There were also a couple of good help topics, about_Language_Keywords and about_Language_Modes that I could reference if I got stuck. My next step was to see what other cmdlets were in the International module. I did that with Get-Command -Module International. That filled in the blanks for me.
For the pieces that didn’t obviously connect to the pictures I had from the customer’s instruction I had some Get cmdlets above to poke around and try to match values. My next hour or so consisted of running the different Get cmdlets and figuring out where the current setting was so I could use the appropriate Set cmdlet to change it. I made liberal use of the help cmdletname –examples paradigm to figure out what the parameter values should be.
After I was finished and was searching to see if I was right I found this Technet article,
How to change display language in Windows 10, that confirmed what I was doing was correct. My script is laser focused on what I was doing, that one is more useful and generic. If you want to understand this more, read through that script.
That’s all there was to it. I can’t reboot the client machine but all of these changes have persisted multiple logouts. I did also have to use the CHCP command to change the code page of the PowerShell window. That did not persist across logins. I think there’s a way to set the default code page in the Registry, but I haven’t chased that down yet.
Now that I’ve had a couple of weeks to catch my breath after SPC I took the opportunity to write a couple of blog posts for Syskit about what I brought back with me. The first one I wrote was inspired by a question I got a lot while I was at SPC,
“I have SharePoint 2013. Should I just skip SharePoint 2016 now that SharePoint 2019 has been announced?”
It’s an involved question with a lot of nuance. To see my full answer read my blog post,
In tonight’s podcast Shane takes over and amazes and enlightens us all on a variety of topics. He tackles such controversial topics as whether “Intranet” should be capitalized or not. He talks about the Microsoft Connect event, some trouble he had with Visio, and the Surface Pro 4. He also offers some recommendations on OneDrive and tells us about some books he’s been reading lately.
As most of you know, I do a wildly successfully weekly SharePoint Netcast. Not only am I the star, I’m also the writer, director, producer, and janitor. As the years have gone by I’ve tried to improve the Netcast, but that almost always means I spend more time producing it. Because of that I’ve tried automate as much of the production as I can. One piece of that is putting all the tags on the MP3 files. The program I use to produce my Netcast, Camtasia, is fantastic, absolutely fantastic. But it doesn’t tag the MP3 files it produces. Windows will let you manually tag the text fields of an MP3 file in Explorer, but you can’t add cover art that way. I’m way too pretty to not be on the cover art of my MP3. So I have had to import the MP3 into Windows Media Player and add the cover art that way. Awfully labor intensive. I’m way too lazy for all that. Time to bring out the big guns, PowerShell.
I spent some time trying to find a way to edit MP3 tags in PowerShell natively. I was surprised that I couldn’t find one. Fortunately PowerShell can wedge its way into all kinds of places. I was able to find a library, Taglib, that did the job. It allowed me to easily add both the text and picture information I needed. Here’s roughly the code I used to tag the MP3 for Netcast 185.
# Load the assembly. I used a relative path so I could off using the Resolve-Path cmdlet [Reflection.Assembly]::LoadFrom( (Resolve-Path "..\Common\taglib-sharp.dll"))
# Load up the MP3 file. Again, I used a relative path, but an absolute path works too$media = [TagLib.File]::Create((resolve-path ".\Netcast 185 - Growing Old with Todd.mp3"))
# set the tags$media.Tag.Album = "Todd Klindt's SharePoint Netcast"$media.Tag.Year = "2014"$media.Tag.Title = "Netcast 185 - Growing Old with Todd"$media.Tag.Track = "185"$media.Tag.AlbumArtists = "Todd Klindt"$media.Tag.Comment = "http://www.toddklindt.com/blog"
# Load up the picture and set it$pic = [taglib.picture]::createfrompath("c:\Dropbox\Netcasts\Todd Netcast 1 - 480.jpg")$media.Tag.Pictures = $pic
# Save the file back$media.Save()
I’m only setting a few properties, but there are many more. To get the full list of properties you can get and set, issue this command:
$media.tag | Get-Member
Most, but not all, of the properties can be written to. Here are a couple of properties to compare:
Properties with only a “get” in their definition, like “IsEmpty” are read-only. You can only get them. Properties that have both “get” and “set,” like “Grouping” are read and write. That’s not something that’s specific to taglib or MP3 files, that’s a PowerShell thing.
Once you’ve set whichever properties you want to set, use the .Save() method to write those changes back to your MP3 file. I’m using this weekly to tag a single file, but this could just as easily be used to bulk tag (or retag) MP3s, or move MP3s around based on information in their properties.
Enjoy. Leave a comment below if you use this in an interesting way.
We’ve all seen it, it happens every day. A coworker gets mad, throws a burrito at the boss and the next thing you know they’re getting escorted out by security. If that person know your SharePoint service account passwords, and the burrito was big enough, your boss might want you to change them all to make sure the burrito-thrower doesn’t get into SharePoint and cause some problems. In this blog post I’ll walk through how to change all of the passwords in a SharePoint 2010 farm without it exploding in your face Wiley Coyote style.
When writing this blog post I’m basing it on the accounts I suggest in my SharePoint 2010 Service Accounts blog post. If you didn’t follow that guide, your experience might be a little bit different. My intention with this guide is to allow you to change your passwords with as little trouble and user downtime as absolutely possible. I recently walked through all of these steps on a customer’s farm and it went very smoothly and with no problems. Without my guiding hand though, your mileage may vary.
It’s important to understand how SharePoint stores and changes passwords in case there’s trouble. The passwords themselves are stored, encrypted, in the Config DB. This is necessary so that you don’t have to enter every password when you join a new server to the farm. SharePoint 2003 was this way and it was maddening. In SharePoint 2010 (and SharePoint 2007 to a point) the passwords are stored in the Config DB, and the servers in the farm are updated via Timer Jobs. When you change any passwords they’re changed in the Config DB and then a Timer Job is created that is run on all the servers in the farm. When you’re executing the steps below, I highly recommend you do them one at a time, and make sure one password is changed on every machine before moving on to the next password. You can keep track of the Timer Jobs in Central Admin > Monitoring > Check Job Status (/admin/Timer.aspx). If one of the Password Timer Jobs fails, do not pass Go, do not collect $200, and do not change the next password. Figure out why the job failed and fix it before moving on.
With that, here’s a list of the accounts, the order I changed them in, how I changed them, and how I verified it worked.
Content crawl account (sp_content)
How to change it
This account is used by the search service to access the content it crawls. Since it isn’t a managed account we have to deal with it manually. We know it’s not a managed account because we didn’t pick it from a list, and we had to enter its password when we set it up. If you don’t have access at the domain level to change other account’s passwords, you can still change this one, as long as it can change its own password. On any domain machine hit Ctrl-Alt-Delete and click “Change a password…” When the change password box comes up, put domain\sp_search (or any of the other accounts we’re changing) in the account box and change the password. This is a pretty low profile account and can safely be changed during the work day.
Once the password is changed in AD we can change it in SharePoint. Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Search Service App. For each of your Search service applications there is a Default Content Crawl account. It’s listed on the front of the Search Admin page. Click it to change its password (or identity). Put the new password in. If you have any Crawl Rules that define another account, you’ll need to go through this process again. Also, if you have multiple search service apps, and they use different default crawl accounts you’ll need to repeat the process.
How to check it
This one is pretty easy to check. After AD and SharePoint have both been updated, just kick off a full crawl. If the passwords aren’t correct or don’t match the crawl will end very quickly and you’ll get lots of top level errors.
User Profile Sync Account (sp_userprofile)
This account is used by the User Profile Sync Service to read the Active Directory changelog, read user information and optionally write user information back to Active Directory. Like the sp_search account above this one is pretty safe to do during the day.
How to change it
You may also have to use the Ctrl-Alt-Delete trick above to change the password for this account in AD. After the password is changed go to your User Profile Service App (UPA) and go to the Configure Synchronization Connections page. Choose the domain connection that uses sp_userprofile and click Edit. Type the new password twice and click Populate Containers. If the password works, your OUs will show up along with the ones you’re syncing will be checked. Click OK to save the new password.
How to check it
Go back into the User Profile Sync service application and manually start a profile sync. A full or incremental will work. If you want to watch the sync as it happens, fire up "C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe" on the machine where the User Profile Sync Service Instance (UPS) is running. That’ll give you more information than Central Admin. If they sync runs, the password change is good.
This section should be how every account in SharePoint 2010 is handled. There should be no need for this blog post at all because of the magic of managed accounts. This functionality is new to SharePoint 2010 and the idea is that you enter a username and password in one place, then pick it from a list everywhere in SharePoint where you need it. There is also the option for SharePoint to manage the passwords. Since the username and password only exist in one place, it’s easy to update. They’re halfway there in this version. You’ll notice the sp_content and sp_userprofile accounts are not managed accounts, so we still have to change them manually. We’re getting closer though, there is hope.
How to change it
To change a managed account password go to Central Admin > Security > Configure Managed Accounts (/_admin/MangedAccounts.aspx). Click the Edit icon next to the account whose password you want to change.
This brings up the next screen.
There are three options for changing the password. The first, “Generate New Password,” tells SharePoint to go ahead and make up a password, set it in AD and change SharePoint’s stored copy of the password to match it. I was curious how strong these passwords are. Using a script I had (link removed due to a request from the script’s author) I decrypted the password SharePoint generated. I was pleasantly surprised.
The password SharePoint generated is 35 characters long, with mixed case letters, numbers, symbols and I can’t be sure, but I think a couple of clicking sounds. As this script shows, should you ever need to discover that password, it’s possible. Be careful using this option with the sp_farm account. If you don’t have the script I have (and I can’t give it to you, sorry ) you won’t be able to discover the sp_farm account’s password and you’ll need to know it for the next section.
Your second option, “Set account to new value,” is like the first option, except you need to come up with the password on your own. SharePoint will change the password in AD and in SharePoint. It should be noted that for option #1 or #2 to work, the service account must have permission to change its own password, which is the Active Directory default.
The third option, “Use existing password” is what you’d use if the password has already been changed in AD and you just need to update SharePoint.
On a side note, at the bottom of this page is a list of all the components in the farm that are using this account as a managed account. This gives you a quick list of things to check after you’ve change the password.
Change these service accounts one at a time. After you’ve changed one account monitor the Timer Job and make sure it succeeds on every member of the farm. Then check its functionality to make sure everything work. Once that’s done, move on to the next managed account.
How to check it
Check the services that use each managed account to see if the password change made its way through. If you want to be super positive, reboot all your boxes. The ensures all the processes are restarted and forced to log back in with the new password.
User Profile Sync Service account (sp_farm)
The farm account (sp_farm) is a managed account, and we changed its password in the previous step. However, the Farm account is used by the User Profile Sync Service (UPS), but not as a managed account. Because we had to manually enter the password when we started the UPS we’ll have to enter the new one there too.
How to change it
Go to Central Admin > System Settings > Manage Services on Server (/_admin/Server.aspx). This page lets you start and stop service instances on each machine in your farm. From the “Server” dropdown choose the server that the UPS is running on. Hopefully its state is “started.” Click “Stop” and let the UPS stop. After it has stopped, click start to start it back up. Hopefully you’re at the June 2011 CU (14.0.6106) or later. The UPS could be a bit of a bugger to get started in earlier builds. Use Spence’s guide to brush up on getting it started. The UPS must run as the Farm account, and you must supply that account when you start it back up. If you chose the “Generate a password” option in the previous step for the Farm account you might be in a bit of a pickle, since you don’t know what the password is. If you have access to the script I referenced above (still can’t give it to you, still sorry about that) you will be able to discover it. If not, you’ll need to change it to something you do know. After you’ve put the new Farm account password in let the UPS start. If everything goes well this will take a few minutes. You can use the MSDN ULS Log Viewer to watch the service instance start and watch for errors.
How to check it
The first check is to make sure the User Profile Sync Service does indeed start. If it does, that’s a good sign. If it does not, it might not necessarily be a password issue. Reference Spence’s post above for troubleshooting steps. After the UPS is started, do a profile sync to be absolutely sure the password change is working.
Install Account (sp_install)
This is the account that’s used to install SharePoint. This is an easy one, as SharePoint (2010, at least) doesn’t store its password anywhere.
How to change it
Log in as sp_install, hit Ctrl-Alt-Delete and Change Password. Type in your new password. Twice. Correctly.
How to check it
Log out, log back in as sp_install.
Farm Passphrase
Not really an account, but I thought I’d include it just the same. This passphrase is created when the farm is created, and is needed when a SharePoint server is added to a farm.
How to change it
Since this isn’t an account, you don’t need to do anything in Active Directory. To change the farm passphrase, use the PowerShell cmdlet Set-SPPassphrase. Since PowerShell hates it when you enter passwords in plain text there a couple of hoops you have to jump through. Type “help set-sppassphrase –examples” to see how to use it.
How to check it
I don’t know of any way to check this other than adding a new machine to the farm.
Secure Store Password
Like the farm passphrase, this isn’t a user account, but it’s a password that’s used to encrypt settings
How to change it
Go to Central Admin > Application Management > Manage Service Applications (/_admin/ServiceApplications.aspx). Click your Secure Store Service App. Click “Generate New Key” in the ribbon.
Type the new password in twice and click ok. SharePoint will reencrypt the contents of the Secure Store database.
How to check it
I haven’t tested this one, but I assume if the password is not correct, the service application won’t display the targets. That’s how it acts when you attach a Secure Store database but haven’t put in the password yet.
Bonus! SQL Server Reporting Services
This isn’t a SharePoint account, but I like you guys, so I thought I’d include it anyway. The customer I was doing this with (no burritos were involved, I made all that up) also had SSRS running. In a weird twist, SSRS was NOT running in SharePoint integrated mode.
How to change it
The directions for changing the SSRS password were pretty simple. Simply rerun the SSRS config tool and put in the new password. I followed the instructions in this MSDN article.
How to check it
Hit the SSRS Reports URL. If it comes up, the password change worked.
Those of you that attempted to change passwords in SharePoint 2007 can appreciate how simple and straightforward this process is in SharePoint 2010. There’s still room for improvement, but it’s pretty solid. The process I used above worked the very first time for every account involved, and resulted in very little end user downtime. While changing all the service account passwords is a big deal, using these steps can make it a low impact, and low stress event.
In my daily perusing of SharePoint blogs a couple of weeks ago I saw a blog post on Jie Li’s blog on how to install Remote Blob Store (RBS) on SharePoint 2010. Imagine my excitement! I was under the impression that using RBS was going to be something we were mortals would not be able to use, but here it was. Why was I so excited? Well, with SharePoint 2003 all content had to go in content databases, no exceptions. As people started putting more content, and larger content into SharePoint the question became pretty common, “Can I store my large files outside of SQL?” The answer was always no. Storing files outside of SQL became the holy grail of SharePoint content storage. It would let you take advantage of all the reasons you used SharePoint; metadata, web presentation, workflows, etc. It also let you use storage that was much cheaper than SQL storage normally is. When SharePoint 2007 came out the answer to that question remained the same, “All content must be stored in SQL, no exceptions.” However, after a hotfix the support for External Blob Storage (EBS) was added to SharePoint. This was almost what we needed. The hooks were there in SharePoint, but there was no way to actually use them. It was handled much like how SharePoint handles antivirus software. There were hooks into SharePoint for it, but the functionality itself didn’t exist in the product. That part had to be handled by third parties or ISVs. Not a lot of ISVs jumped on this, as the interface exposed to them wasn’t great, and it wasn’t clear what the upgrade path would look like. Again, storing large files outside of SQL seemed just out of reach for the average SharePoint administrator, until now…
That brings me back to Jie’s post. I knew that SharePoint 2010 would ship with RBS support, but I wasn’t sure what RBS products we’d be able to use. Jie’s post not only showed how RBS could be used, but provided an actual RBS provider. That’s was pure gold. The RBS provider Jie linked to uses SQL 2008’s Filestream support. That works for me. The rest of this blog post is how I installed RBS and got it working.
Again, everything I’ve done here is based on Jie’s blog post and the links inside. Only a couple of things are things I had to figure out myself.
I already had a VM with Windows 2008 R2, in a domain. It had SQL 2008 R2 with the November CTP on it. It also had SharePoint Beta 2 (build 14.0.4536.1000) installed on it, and I had been using it a while. There were several content databases defined with a few site collections. The first thing I had to do was enable Filestream in SQL 2008 R2. I used these instructions on MSDN. Once I had the instructions, it went very smoothly. The only snag I had was I initially ran it as the wrong user. In my VM, SQL is running as contoso\administrator. SharePoint is all running as contoso\sp_farm and that’s the account I logged in as normally. That account did not have the permissions to enable Filestream. After I ran it all as Administrator it worked. Now came the fun part, RBS…
In preparation for RBS I created a new Content Database for it to use, since RBS is scoped at the content database level. I used Window PowerShell to do it, since that’s what the cool kids are using.
The command I used was New-SPContentDatabase –name WSS_Content_Blob –WebApplication http://shaerpoint –MaxSiteCount 1 –WarningSiteCount 0
Next I went into SQL Management Studio, as contoso\sp_farm, and ran a few TSQL commands to configure my new database for RBS. Here are the commands I used:
Here’s the text:
use [WSS_Content_Blob]
if not exists (select * from sys.symmetric_keys where name = N'##MS_DatabaseMasterKey##')create master key encryption by password = N'Admin Key Password !2#4'
use [WSS_Content_Blob]
if not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider')alter database [WSS_Content_Blob]
alter database [WSS_Content_Blob] add file (name = RBSFilestreamFile, filename = 'c:\Blobstore') to filegroup RBSFilestreamProvider
I was following the directions from this MSDN post, but I had to make a couple of changes. First, I had to make sure I had the correct database name, WSS_Content_Blob, everywhere necessary. Second, I manually created c:\Blobshare before running the TSQL commands. That was a mistake. SQL needs to make it on its own when you run the third command. Deleting c:\Blobstore fixed that and the command ran successfully.
Next step was to install the RBS bits on the SharePoint servers. (Download RBS_X64.msi) In my case it was pretty simple because SQL and SharePoint were on the same machine, and I only had a single SharePoint server. Here’s the command I used to install the RBS bits:
This install seemed to happen immediately. However it kicked off an msiexec service that ran for a couple of minutes. I had to watch it in Task Manager to see when it was finished. I was also monitoring the rbs_install_log.txt file to see when the process was finished. I was looking for the phrase “Installation completed successfully.”
If I would have had more SharePoint servers I would have had to install that on all of them, or SharePoint would have been very unhappy.
You can double-check the database was changed correctly if the rbs tables appear in it. That will look like this in SQL Management Studio:
The last step, before feeling the glory that is RBS, is to go back to our old friend, Windows PowerShell and enable RBS on our content database from a SharePoint perspective. Here’s what the PowerShell looked like:
Here’s one place I had to deviate from the MSDN article. It says the first line should be $cdb = Get-SPContentDatabase –WebApplication http://sitenameThat didn’t work for me. I suspect the person writing that article had a web application with a single content database, so that command would only return one SPContentDatabase. The web application I was testing this on had three content databases, so $cdb had a collection of SPContentDatabases, which doesn’t work for the next line. Reading through the PowerShell it looks pretty clear that $cdb should contain a single SPContentDatabase object. I went through the RBS install three times and had the same behavior each time.
The last step was to test RBS and upload a file and see where it ends up. The rbs_install_log.txt was 1.2 MB and a good candidate for the test. I created a site collection (with PowerShell of course) and uploaded that text file. To see if RBS worked, I navigated the c:\blobstore directory to see if my file was there. Here’s what I found:
Looks like it was successful. I went through this three times and it worked every time. I tried various sizes of files and various operations on those files. I added versions, deleted them, added metadata, indexed and searched for them. It all worked just fine.
I hope this blog post inspires some of you to install RBS and play with it yourself. I do have another blog post planned where I go a little more in depth with what I found in RBS.
) you won’t be able to discover the sp_farm account’s password and you’ll need to know it for the next section.
