Publishing blog posts to multiple blog sites with Word: a test

I was testing out blog functionality with a coworker (@Nathan_Locke) and he asked an interesting question: Is there a platform available that will let you publish to multiple blogs at once. My first idea was Word. Fairly simple tool to use (although it writes seriously jacked HTML) and on the surface it appears as though it will publish to multiple blogs at once, or at least let you publish to one then publish to another several seconds later manually. Note: Blog posts to WordPress require images to be uploaded first.

So I’m going to give this a shot. But before I do that, I ran across this interesting Warning while registering my WordPress account with Word:

So I get the gist of what’s being noted here: since I’m not sending this via a secure channel there is the possibility of someone intercepting my username and password. Should I be leery of publishing content this way?

Where’d my InfoPath options go?

Real quick post here.  Working with a business partner who wanted to create InfoPath forms. Easy enough right? Oh but wait, she doesn’t have the option. Is there a configuration in CA to modify? Is it a down Service App? What do I do!?!

Well, for one I knew it was a site setting or feature since other site collections allowed users to use InfoPath. So I figured I’d start at the site collection features. Navigate down the page and lo and behold:

SharePoint Server Enterprise Site Collection feature

I go ahead and hit Activate. It chews on that for a minute or two and after that you should see this:

SharePoint Server Enterprise Site Collection feature activated

Now my user can create any and all InfoPath forms they want.

Side note: I know this isn’t the sexiest post, but I found it to be one of those “Gee, I wonder how I turn that functionality on” and figured someone else might run into the same issue.

Source Control for your code snippets

You can drop almost any piece of HTML, CSS, JavaScript, jQuery, etc. you want on to a SharePoint page. As long as you possess Designer permissions or better, you can drop this code on to a page or pages and provide your users a richer UI experience while sparing you the headache of placing files on the server file system. It’s extremely easy to drop a Content Editor Web Part (CEWP) onto the page and plop your code down. But there are 2 inherent problems with this approach:

  1. Zero Source Control
  2. Difficult to repeat

So how do you solve these 2 problems?

  1. Save your code in a text file
  2. Place the text file in a separate, dedicated document library for these snippets

Once the file is in the doc library, you can paste a link to the text file in the CEWP. By creating one single source of the code, you ensure consistency amonth other CEWP(s) that call the same text file. It’s just good coding practice and it’ll make your life a lot easier in the long run. 

The CEWP has been capable of linking to a text file since at least MOSS. SharePoint 2010 has just made it slightly more difficult on developers to drop code on the page by hiding the HTML editor in the ribbon. This is a change that I welcome and have come to appreciate.

One last note, make sure that your users have at least Read access to this text file doc library. Generally, I break inheritance on this specific library and add domain/domain users with Read permissions. Just one less thing I have to manage.

The command line IS your friend: SP hotfix crisis averted

I’ve always been somewhat nervous about using the command line for doing things. But today has turned me into a convert.

I had to install a particular hotfix in order to remedy an issue we were having with alerts.  I did my due diligence by documenting my procedures, making sure to fully research EVERYTHING. I tried the hotfix in DEV and everything looked good to go. I followed Microsoft’s guide TO THE LETTER (link). Last thing to accomplish was to run PSConfig. I figured why tempt fate by doing it in the command line and just do it in the GUI.

I let the Wizard do it’s thing with each server, checked Central Admin (CA) to make sure everything was good, and then figured I was done. 25 minutes tops. I opened a fresh browser and navigated to the site. NOTHING. [enable freak out mode]

I did EVERYTHING I was supposed to do. I started to panic. Would I really need to roll back? CA told me everything was running correctly. I restarted IIS. Contemplated rebooting. I had no idea what to do.

Then, on a hunch, I figured why not try it in the command line. There are lot’s of times I’ve tried to do things in CA, only to find PowerShell or STSADM is the only way to ensure it gets accomplished. So I went to Google and did a little searching and I came up with the following:

  1. Open up a command terminal (Run > cmd > Hit enter)
  2. Change Directory to the BIN folder in the 14 hive (cd C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14BIN > Hit Enter)
  3. And type in the following command:

    PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

Once completed I hit the site again and we’re back. Whew.

Let this be a learning lesson. If you have the choice to do it in the command line vs. GUI, always pick the command line. Will I follow this advice every time? Probably not, but I’m a glutton for punishment.

My first 2 weeks @ Trek: Setting up a Development Environment with Production Data

So I started as the new SharePoint administrator at Trek Bicycles (in Waterloo, WI for those of you keeping score at home) last Monday. It’s been quite the whirlwind thus far. The biggest learning curve I ran into was setting up our development environment with a snapshot of production data. In all my prior gigs other people were responsible for that. Here at Trek I’m the lone ranger. So I foraged ahead with my admin handbook, navigated to my dev environment’s Central Admin, and clicked on “manage web applications.”

Note: This post assumes you’ve got an available (and functioning) SharePoint 2010 environment, a breathing database administrator, and working knowledge of Central Admin.

Click New in the Ribbon and you’ll get this mean nice form.

Add a New Web App

 You see 10 sections and you think “Gee, how hard could this be.” Well, it’s not hard per se, but it ain’t easy either.

Authentication

Depending on your scenario, you’ll generally pick Classic Mode Authentication.

IIS Web Site

On to the IIS Web Site section.  Here it is important to note that you need to have your domain (i.e. your web address) already setup and have it pointed in the right direction (i.e. pointed to the right IP address). In my case, I only have 1 Dev server so it’s not that complicated. I e-mailed the person in charge of IP addresses, told her I needed a new A Record (the web address), gave her the IP address of the server, and we were off and running.  You’ll want to create a new IIS web site. Name it something you’ll easily recognize in IIS. Use port 80 (http) or 443 (https). If you use any other port you’ll have to add it to the end of the URL. For example, if you use port 4455 and your address is https://www.getaclue.com, you’ll need to have users add :4455 to the end of their URL in order to hit the site correctly (https://www.getaclue.com:4455).  Shout out to Brian Winkers for the help on that.

Next you’ll need to add a host header. Using the example above you would add [www.getaclue.com] (note: no brackets). You can leave the Path alone. In fact, I recommend you don’t touch it. Once that’s done you’ve completed the IIS section. Moving on . . .

Next half of the form:

The rest of the form

Security Configuration

 These are 3, subtle, yet oh-so-imporant radio buttons. For now, let’s just leave the first 2 alone. Kerberos is a beast and if this is for an internal network you wouldn’t want anonymous access. If you’re using port 443 it’s probably a good idea to use SSL, especially if it’s internal. You’ll need to buy an SSL certificate from an external vendor (I recommend RapidSSL).  The certificate is installed on the server(s) in your environment via IIS, but that’s a topic for another blog article.

Public URL

Here you put in your URL. Pretty straightforward here.  I don’t know what Zone does, and I’m sure it’s important, but this blog is called SharePoint Rookie; not SharePoint Expert. 

The rest of the form

For the rest, I would just leave it alone unless you do not have an Application Pool account in the App Pool section. Again, topic for another blog.

Now hit OK at the bottom of the form and wait for SharePoint to work it’s magic. It’ll take 30 seconds or so, but once it’s done the Web Applications page will refresh with your brand-spankin new web app provisioned.

The database

Last step is to connect the copy of production’s database to your newly minted Dev web app. Contact your Database Administrator (DBA) and ask him/her to put a copy of the production content database on the Development SQL server. It’s important to have a good idea of what’s in Production because you’re going to reproduce it on a different server. Depending on where you work or where you’re doing this, this may be a bad idea. Check with whoever (boss, director, higher-power) you may need to and make sure this is okay. Once you get the go ahead, do the following:

  1. Click on Application Management in the left-hand navigation
  2. Click Manage content databases
  3. Make sure the correct web application in the dropdown is selected (This would be the one you created above)
  4. Click “Add a content database”
  5. Add the correct database server name and the correct database name

Now if you and your DBA did everything right (and I didn’t forget to mention anything here) you should have a production copy of your team site(s) now running in dev. Cheers!