I saw a tweet about Live ID blogs going to go over to WordPress, and had to check it out. Here's a post on the Windows Live blog about it:
I've got two Spaces blogs, one about Windows Server stuff and one about Windows 7 stuff. The Windows Server blog is actually the resurfacing of my first blog. I've not been there much this year because all I've been doing is writing the Mastering SPF book.
I like my Spaces blogs (and liked my first blog there when it was msn spaces, remember when?), and will be sad to see them go WordPress (or go away entirely by next spring). I didn't really like wordpress, back in the day when I was checking out different blogging options online.
Keep in mind this "upgrade" will literally change the URL of the blog (but they'll keep the Spaces redirect so people's links, favorites, RSS feeds should still work). If you have stuff hard coded, be sure they still work after the change.
I thought if any of you have a Spaces blog (or two) you might want to be given some warning. Apparently a lot of people don't realize that Microsoft is making this change.
If you sign in to your spaces blog, you will immediately be taken to a page that leads with "Windows Live + WordPress." They don't absolutely demand that you move your blog to WordPress right away, but they do state that the "clock is ticking" if you don't "upgrade" and that the deadline is March 2011.
(if you don't want to upgrade, you can temporarily continue to use the blog as is, download all your blog entries as html files, or just delete your site now...)
I am disappointed that Microsoft is basically pawning off 30 million people's blogs to WordPress (if they'd wanted to be there, they already would be). It would have been great if Microsoft had invested a little on the blogging capabilities of SharePoint and maybe moved those 30 million people to SharePoint online instead.
Some of the things you lose in the "upgrade" are your drafts, your theme, gadgets, guestbook, and lists (I spent a lot of time making and updating my lists...).
Nonetheless-- for those of you who haven't logged in for a while, I thought you should know-- It is not a ruse, you haven't been hacked-- your Spaces blog is going away next spring, the clock is ticking, unless you "upgrade" it to WordPress.
Now you know.
Wednesday, September 29, 2010
Saturday, September 25, 2010
A security advisory has been released concerning a known ASP.NET security issue and the danger it can pose for those of us who have SharePoint deployed (which uses ASP.NET, and therefore can be compromised).
The problem, in an oversimplified example, is that due to this vulnerability, an attacker can send information (cipher text) to the server, and see if it was decrypted correctly based on the error messages that are returned, until they know that they can get in and get private info.
Microsoft does not yet have a fix for this issue, and if you are worried (say, if your SharePoint implementation is internet facing), they offer some workarounds until they do have an official hotfix or patch you can download.
The workaround is detailed at: http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx
The official (and not super helpful) security advisory is at: http://www.microsoft.com/technet/security/advisory/2416728.mspx
A blog by someone named Scott Guthrie, who seems to be super knowledgeable about this security issue, has two entries concerning it:
The first, as of Sept. 19 is: http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx
The follow up, Sept. 24, is: http://weblogs.asp.net/scottgu/archive/2010/09/24/update-on-asp-net-vulnerability.aspx
My environment, right now, is completely isolated, so I am going to hold off messing with the settings until I finally finish creating new material for the book. But I wanted to let you all know about the issue now, in case it compromised your environment.
Friday, September 10, 2010
It started with not being able to activate wiki page home page feature (or issue with features if you load balance your site...)
I am currently super, super busy finishing up chapters in the SPF book, but I needed to write this down somewhere...
So I finished writing the first draft of chapter 16. It involved, among other things, installing a second server on the farm and enabling load balancing so the readers could see it in action.
That meant that, at this point, my virtual machine of my SharePoint Foundation installation has two SPF servers load balancing content.
I was reading over some edits of one of my chapters and needed to see the home page without it being a wiki page for a moment. Now, there are a couple of ways to do that, the easiest being deactivating the wiki page home page feature (yeah, funny name) , the next easiest being deleting the Home.aspx page from the Site Pages library real quick (restoring it from the recycle bin takes seconds).
I am really, really behind on my edits, so in my rush, I just deactivated the feature.
I checked the stuff I needed to check, then went back in to re-activate the feature-- and it failed. I went to the other server in the set, and it failed there. I did an IISRESET on both, still failed.
I dropped to the powershell console and tried a get-spfeature command (it brings up a long list of features available for the farm at the moment). Wiki page home page was listed.
So I marked the ID of the feature (okay, so I am an old skool admin, not a developer, and it's just easier for me to grab the ID than write a bunch of pipe stuff. I keep it easy)
I then tried to enable the feature for the site manually, using the enable-spfeature command:
enable-spfeature -identity (paste marked ID here) -url http://theurlofmyrootsite
And it failed, saying " Enable-SPFeature : The Web application at http://spf2 could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application."
What?! I know that site exists, and that I typed it's URL correctly, I was just on it.
I tried an IISRESET, no luck, on both servers, still no luck...
So I tried the same command on the other server, thinking maybe it had something to do with it. Nope.
Then I realized something. I had changed the default zone of the site to be the load balanced address.
::head smack:: Doh!!
I then reran the command but with the load balanced address. (in my case that would be http://sharepoint)
enable-spfeature -identity (paste ID here)
And it worked perfectly!
So what does that say?
It says that in the GUI, ie in the Manage Features for the Site page, when you hit the Activate feature button, it points to the site's original URL when the site was created-- so if you change the default zone for the web application of the site you are activating features on, and you don't include the old URL in AAM to point to the web application, the Activate button might not work.
Bottom line: Either plan to activate or deactivate features via PowerShell if you remove the original URL from AAM for the site, or always include the original URL in AAM for a site (even if you don't want users to use it).