I'm making some significant strides in learning about, setting up, and architecting the Managed Metadata Service and Content Type Hubs for my organization. Nothing especially problematic occurring, but it's just such useful stuff that I have to talk about it after it's done. There's an excellent article by Marcel Medina on the administration side of setting this up to work end-to-end.
I've already been trying to get MMS integrated slowly, and now I'm working on a Content Type Hub, but discovering that I've got collision issues trying to create site columns with different data based on context. I started thinking about maybe using multiple Content Type Hubs with multiple MMS services, but wasn't sure how that would affect my term store. Now, I see that I can do exactly what I need with this arrangement (and not an excess of overhead), so I'll be creating a number of departmental MMS service applications and Content Type Hubs for each one. There's a good example scenario in this TechNet article which shows how this might be used.
Showing posts with label Managed Metadata. Show all posts
Showing posts with label Managed Metadata. Show all posts
Tuesday, September 17, 2013
Thursday, February 14, 2013
Adventures in SP2013
I've finally gotten around to setting up a demo VM of SharePoint 2013. Of course, it was necessitated by looking forward to see if we could utilize it to solve a problem a user is having now, so I haven't exactly gotten to dance around in the snowflakes and stare in awe and wonder at the freshness of it all... That said, I'm very much liking what I see so far.
I've had a couple of minor gotchas arise during the testing. For starters, I'm using CriticalPath's SP2013 VM setup guide (free registration required). It's been really good so far, though I got briefly thrown off track due mostly to a dumb mistype on my part and a red herring in the guide. When setting up your new users in Active Directory, the CriticalPath guide includes a PowerShell script and annotations in the document which state that it will handle SQL permissions.
This is not accurate. It's also not a problem, because the SP installer does it for you (provided the account you run the SP installer under has permissions to write to the database to begin with). Just provide the account/credentials for your would-be farm account, and SP will set all the privileges accordingly. That's nice.
When SP offers to create your first site collection, I was thrown off slightly by the fact that the installer defaults to the /sites/ managed path. I had assumed that the root site collection (eg - "/") was going to be created by default, and so after the configuration wizard completed and I couldn't visit http://mynewvm/ but http://mynewvm/sites/test worked, I was a little puzzled.
Part of my testing scenario involved setting up some metadata terms for working with refiners. It was easily done in the site settings for my test site, but then when I was nosing around in the Managed Metadata Service application, I couldn't seem to edit the term store at all. After a short time browsing the Internet unsuccessfully, the reason finally dawned on me - I didn't have permissions to edit the global term store because nobody is defined as a Term Store Administrator! I added myself here, saved the changes, and voila - I can now start creating termsets.
More later.
I've had a couple of minor gotchas arise during the testing. For starters, I'm using CriticalPath's SP2013 VM setup guide (free registration required). It's been really good so far, though I got briefly thrown off track due mostly to a dumb mistype on my part and a red herring in the guide. When setting up your new users in Active Directory, the CriticalPath guide includes a PowerShell script and annotations in the document which state that it will handle SQL permissions.
This is not accurate. It's also not a problem, because the SP installer does it for you (provided the account you run the SP installer under has permissions to write to the database to begin with). Just provide the account/credentials for your would-be farm account, and SP will set all the privileges accordingly. That's nice.
When SP offers to create your first site collection, I was thrown off slightly by the fact that the installer defaults to the /sites/ managed path. I had assumed that the root site collection (eg - "/") was going to be created by default, and so after the configuration wizard completed and I couldn't visit http://mynewvm/ but http://mynewvm/sites/test worked, I was a little puzzled.
Part of my testing scenario involved setting up some metadata terms for working with refiners. It was easily done in the site settings for my test site, but then when I was nosing around in the Managed Metadata Service application, I couldn't seem to edit the term store at all. After a short time browsing the Internet unsuccessfully, the reason finally dawned on me - I didn't have permissions to edit the global term store because nobody is defined as a Term Store Administrator! I added myself here, saved the changes, and voila - I can now start creating termsets.
More later.
Subscribe to:
Posts (Atom)