3/2/2010I work with a large team of developers currently and am the only SharePoint Administrator. There are consistently several projects in development and QA at a time. I have been working on trying to keep these projects from interfering with each other as well as ease of deployment from one environment to another. I have created a very short (5 questions) survey for administrators who may be facing the same situation. I would appreciate if you would take a few moments to complete the survey here. I will share all of the results and probably post more about this in the future. Thank you! 2/18/2010Recently I learned that even experienced administrators make boneheaded mistakes. Yes, you guessed it, yours truly made a crazy mistake. It took me a while to figure out it was actually me, but I did finally figure it out. Let me set the scene for you. I’m working hard and moving a site from the development farm (single server) to the QA/Testing farm. Standard procedures, right? I backed up the site using a method I’ll detail later in this post on the dev server, copied the files to the app server of the QA farm and then attempted to restore them (again, I’ll detail this shortly) and got this strange error: Your backup is from a different version of Windows SharePoint Services and cannot be restored to a server running the current version. The backup file should be restored to a server with version '1178817357.0.45671568.0' or later. So of course I begin checking my versions on the farms. I went into Central Administration on both farms and went to the Operations tab and clicked on “Servers in Farm” in each farm. Both of them were the same: 12.0.0.6504 for all servers in each farm. Hmmm… that weird version number was throwing me. So I thought I’d do a search for the error. Nothing, nada, zip, zilch, you get the picture. There were some similar, but nothing with those exact numbers. The odd thing was, that those results that were similar talked about using a SQL backup and trying to restore that using stsadm. Well that’s odd, right? I know I used an stsadm command on both servers. What’s the deal? Then it hit me. I backed up the site using stsadm –o export –url http://sitename –filename d:\sitename.dat. And what was I using to try to restore? You guessed it: stsadm –o restore –url http://qasitename –filename d:\sitename.dat. Okay, wow… bonehead mistake. In order to use the export operation, you have to use import to bring it back in to your new site. In order to use the restore operation you have to have a file that was created using backup instead of export! Really unusual that it would give you the error that seems to indicate that it was the wrong version of SharePoint instead of the wrong type of file. Once I used the correct operation, the site imported correctly and all was well. 1/12/2010In this super secret mission that I undertake - that’s right call me double-oh eight, a little curvier than James Bond, but still licensed to kill - a custom web part was developed to look at the “My Tasks” view of a particular tasks list and display that information and perform some actions based on this view. However, when the new web part was deployed from the developer’s personal virtual machine to the dev machine for further testing, it didn’t perform as expected. After several bouts of troubleshooting, it was determined that the “My Tasks” view template, not the view itself, was causing issues with the functionality of the custom web part. After much research, I found a way to remove that view template for the dev machine. This should NOT be attempted in production or used in production at all as it involves modifying the file in the 12 hive. We are still working on a way to either make a feature that will remove this without affecting the tasks lists definition or will create a new definition of a tasks list that can be used that does not include the view templates. This is strictly blackops and should not be attempted by mere mortals, I will disavow all knowledge of and responsibility for your mission. In this view, you can see the links that point to creating a new view from the view templates. This is out of the box, and not a view that is already created. 
After much searching, I found the definition of the tasks list here: c:\program files\common files\ microsoft shared\web server extensions\12\TEMPLATE\FEATURES\TasksList\Tasks\schema.xml. This xml file was not easy for me to decipher, but I found out from a member of my vast spy network, Becky Isserman, that I could open this in Visual Studio and it would make much more sense. Oh my, she was right! You can collapse and expand nodes of the xml file so that you can see only what you need to see. Now, to figure out what you need to see… 
This was not as hard as I thought it would be. It involved 2 things, both searching the xml file and looking at the tasks list through the browser. A search of the xml file for the view name My Tasks takes you to a particular node of the file, but is this the right one? When I went to the tasks list in the browser and went to Create a View, then found My Tasks in the Start from a view template section. I right-clicked on it and copied the shortcut and pasted it to notepad. At the very end of the link you will see: BaseViewID=2. This helped as each view that was in the xml file was labeled with the base view ID number! I quickly found the node and collapsed all of the other nodes of the xml file that were views leaving only this one expanded. EWWW… 1147 lines of xml for this view! So I did what any good admin would do, I made a quick snapshot of my VM, copied and pasted the lines into notepad for safekeeping, and deleted the lines, all 1147 of them. Then I reset IIS and surveyed my handiwork. This BROKE every tasks list already in existence (thus the reason you do NOT use this in production, along with modifying the 12 hive!). However, when I created a new tasks list, there were no view templates, and this solved that issue. I deleted the new tasks list, added the 1147 lines back to the xml file and rest IIS again. All of the pre-existing tasks lists worked again. So, now the next assignment is to find a good developer to write something to keep these 1147 lines from messing up a custom web part, that should be an easy mission, right? 12/23/2009I have spoken at a couple of SharePoint Saturdays on using SharePoint’s web services in InfoPath to create no code solutions. I have been asked by some of the people who saw me recently at SharePoint Saturday DC to upload the demos and slides. Please note that none of these demos have sound. I explained the process as I presented them. I have finally been able to get them all uploaded, so without further ado… The slides for my presentation: InfoPath and Web Services. Demo #1 Designing a form based on a Web Service Demo #2 Creating a connection in a blank form Demo #3 Preview the data with drag and drop Demo #4 Add attachments to list items Demo #5 Create a site Demo #6 Part 1: Auto populating information about the currently logged in user This information is also detailed here. Demo #6 Part 2: Adding the contact selector This demo as well as the next demo can also be found in detail here. Demo #6 Part 3: Auto populating another user’s information 12/3/2009Recently I was faced with a situation that I know many will be faced with in the coming months and years. An initiative has been placed to conserve both money and physical space in most organizations. As this and disaster recovery has become more and more important, virtualization has become a big issue and many are moving toward making most, if not all, of their servers virtual servers. I have no issue with this, to a point. I won’t go into all of the pros and cons of virtualizing the different parts of SharePoint. My personal opinion is that virtualizing adds overhead to your servers, so if it makes sense and isn’t causing an issue, do it, if it doesn’t make sense and causes issues, don’t do it. My one exception to this is SQL for SharePoint. I am not in favor of virtualizing SQL for SharePoint, at least in larger farms. It adds enough overhead that you usually see some decrease in throughput or increase in latency or both. But personal opinions aside, this was the situation I was facing. To virtualize SQL or not to virtualize SQL for a SharePoint deployment? In the course of my studying up on this, I conducted kind of an informal poll on twitter, email, and IM. I received a lot of great information and opinions on the subject from MVPs, experts, and even Microsoft employees. Thanks to Woody Windischman for posting a great article about it after I included him in my poll. So after talking with everyone and getting a pretty general consensus that most people wouldn’t virtualize SQL in most deployments, it made me think about what makes a best practice. Do we consider not virtualizing SQL a best practice because 22 of the 25 people I polled wouldn’t do it, and the others only under specific circumstances? A best Practice is defined as: the best way to do something: the most effective or efficient method of achieving an objective or completing a task according to the Encarta World English Dictionary. Is there only one best way? Is it a best practice if it doesn’t work for your organization? Some experts think that best practices are non-negotiable, some think that they are not hard and fast rules so much as guidelines that should be used to help you make the best decisions. I am now of the opinion that a best practices is the best way in your situation of making things work. Your organization will have initiatives, and goals that may not include IT (I’m not speaking to you IT consulting firms, this doesn’t apply to you). They may have cost savings initiatives that require server consolidation, which may include virtualizing SQL, even if you think it isn’t the best thing for the SharePoint farm, it could be the best thing for the overall company goals. This holds true for other “best practices” you may need to implement. Present the pros and cons that you have researched and state your opinion, but don’t take it personally if the opinion of the company is to do the opposite of what you would prefer. You have stated your case, and they are willing to accept the risks. All you can do at that point is be prepared with a plan to recover if needed. Hey, it could surprise you, they may be willing to wait a little longer for a page to load if it can save them $50,000. Heck, I might be willing, too! Happy SharePointing! 11/30/2009A very creative friend of mine was working on creating a site for surveys. During the creation, only the link directly to the survey would be sent to the people filling it out. They did want this on a separate site collection from all other sites, but did not want the users to be able to go to the top level of the URL. They wanted this to redirect to another existing site. This is great, however, my creative friend wrote a javascript in a Content Editor Web Part to make the redirection, before completing the rest of the configurations on the site. This caused great pains, as every time the url was accessed, it sent you to a different one. Makes it a little hard to finish the customization, huh? After a frantic conversation about the problem, the solution was actually a fairly easy one. I instructed to type the url of the site, include the /default.aspx at the end and add ?Contents=1. This allowed the person to go straight to the web part management page and remove the offending web part from the page so that customization could continue. It was kind of an easy approach, I’ve used this many times when web parts cause errors, or to review and see how many closed web parts were on a page that was rendering slowly. Thankfully, since the redirect was on the page itself, this method to review the web parts still works. However, quick lesson learned. Save your redirects until you are sure you are done! Happy SharePointing! 11/25/2009I recently attended a presentation by Lee Reed entitled 8 Things You Must Do to Drive SharePoint User Adoption. I have seen this presentation (or a version of it) once before at SharePoint Saturday in Atlanta, GA. He mentioned during his presentation that he had added a slide just a few minutes before he started his presentation. His slide indicated that Enterprise2.0 had surmised that you couldn’t “drive” adoption. That driving adoption was akin to pushing or pulling and would be met with resistance. I thought about this over the weekend and the last couple of days. It really made me pause for a minute. If you haven’t seen Lee’s presentation, it is a good one. He mentions things like knowing how your organization collaborates, not boiling the ocean (trying to bite off too much to chew), and allowing organic growth, but with control. All of these are good things you should know going into a SharePoint deployment, and have a plan in place for them. I think the dilemma Enterprise2.0 is facing is the negative connotation implied by the word “drive” it does have a pushing or pulling connotation, like herding. End users seeing that would think “Come on, we aren’t cats or cattle,” right? Maybe we should think more on things we can do to promote user adoption. All of the things that Lee mentioned are things that we can do, most of them behind the scenes, that will improve the deployment and acceptance of SharePoint within an organization. So how do you “promote” user adoption? Well, I think like Lee stated, there are things we can do behind the scenes, preparing and configuring SharePoint specific to the needs of the organization, allowing controlled growth, taking on only those solutions that are needed and when they are needed. There are also some very public things we can do, like training and starting internal user groups that will promote adoption. I mean really, why would someone use SharePoint if they don’t know how? Most users are not the technophiles that us IT people are. They don’t sit down and look at SharePoint and say wow, let’s just play with this tool for a while and see what all it can do, let’s see if I can change it, mold it, bend it to my will, or even break it. End users typically are only using SharePoint for a specific task in their work day. They don’t want to talk about it, learn more about it than they have to, or even research it. They just want it to work when they need it, and also how to use it to complete their tasks. So here’s some ideas I have about promoting user adoption other than those great points that Lee made. 1. Ensure that you have a system that is highly available. SharePoint, if it is going to be used by non-IT people should always be there when they need it. Communicate its availability to your users. Let them know it is there for them, and will be there for them. Plan your deployments so that you can limit downtime. 2. Design for specific needs. Does everyone need a My Site off the bat? Generally, no. Someone will approach you stating “I need a place to store my personal documents while I work on them” usually in the form of “I need a file share that only I can use” or something like that. Give them a My Site, show them how to use it. What a great way to be introduced to SharePoint. “MY own personal site. WOW. What I could do with this.” These are all comments that you might hear when you give someone their own site. Use the same strategy for other needs. Don’t just create a team site for each department off the bat, not all of them will have a use for them. Let these things happen as they are needed. 3. Branding is important, but not THE most important thing. My first 2 years working with SharePoint, we had zero branding, it was all out of the box and themes. This is partly because it was 2003, so branding was not very easy, and also because, why was it important? We were using the functions it provided. Yes, people do tend to like the flashy, pretty, and branded sites more than the ones that look “sharepointy.” But it is entirely OK to roll out a site without 1000 master page changes and only use a slightly customized themes. Let your users know that this is a first iteration of your solution. Let them contribute to the branding by giving suggestions. 4. Contests are amazing ways to get people to play with SharePoint. Especially if you are going to roll it out as an intranet solution. Let your users have a contest to “name” the intranet. I’ve seen lots of different names, Insider, Source, CompanyWeb, you name it, I’ve seen it. But it allows your end users to be involved in the process. Another thing I have seen is that after an intranet is rolled out, one company had a “treasure hunt” with a new treasure to find daily for the first week, then randomly after that. Once the item or information was found there were small prizes awarded (think cookies or small value gift cards, use your imagination). There are many more things you can do I’m sure to promote user adoption than all of these. Please feel free to share them in the comments. Happy SharePointing! 11/21/2009I have been given the privilege of speaking at SharePoint Saturday in DC on December 5th. I am both excited and nervous about this. I have spoken at a SharePoint Saturday in the Ozarks. However this will be one of the larger SharePoint Saturday events where I will present. I am excited about getting to speak to the SharePoint community in DC. I know that there is a lot of community involvement there. My first introduction to the DC SharePoint community was at the Best Practices Conference in August. Many of the community members who were not attending came out to the SharePint and they were very welcoming and a pleasure to meet and talk with. I am looking forward to meeting and visiting some old and new friends at this event. I will be presenting a session about using InfoPath and SharePoint web services to create no code solutions. I am going to be focusing on 2007 for this presentation as that is what is currently being used in production at most places. I look forward to seeing you there if you are attending! I think it has already sold out, but there is a waiting list if you haven’t! Please visit the website: http://www.sharepointsaturday.org/dc for more information. 11/6/2009My friend Joy Earles (@joyknows on twitter) recently proposed a question to me that she was proposing to several people in research for a presentation she was preparing. The question: What would you say are the primary strengths and weaknesses of OOTB customization vs. SPD vs. custom code? Since there are so many ways to answer this question, I thought it would be a good idea to write up a blog post with my first response by instinct, but also allow others to contribute to the answer, you may have other insight into this from a different perspective. If you don’t know by now, I am primarily a SharePoint Administrator, so my answer comes from the perspective that keeping the farm running smoothly is my focus. With that in mind, my first instinct was that the two biggest risks of customizing SharePoint are performance and upgrade (including patching). I know I know… security falls in there somewhere, but I am basing this on the assumption that security was implemented properly, and would continue to be. The OOTB (out of the box) customization that is done from within the browser, which includes adding and removing web parts, adjusting the theme, changing the navigation, etc… is the least risky of these methods of customization. It poses no real risk with upgrade and patching since you are not modifying anything that SharePoint does or the object model. The bigger risk here is performance. Although with training this can be minimalized, it is still a very real risk. Despite how many times you repeat “don’t click the X, that only closes the web part, it does not delete it from your page” users will still do this. When a web part is closed, it still is loaded when the page loads, you just don’t see it. I have had users call wondering why their page loaded so slowly when they only had a few web parts on it. Luckily, when you get these calls, there is an easy way to see what is going on. Simply add “?contents=1” to the URL of the page, and you can see what web parts are added to the page, and what ones are “closed.” Then you can remove those closed ones and the page should load more quickly. Customization using SharePoint Designer (SPD) poses slightly more risk than OOTB customization. The risk is still present with performance, but in this case, for different reasons. Back in SharePoint 2003, there was the ability to use SPD to customize, and the terminology then was “ghosted” and “unghosted” with ghosted being the better of the two. Today, the terminology has changed, and is “customized” and “uncustomized” with uncustomized being the better of the two. Susan Henry has a great post on this here. Basically what happens is that uncustomized pages are rendered from the content that is stored in the contend database in combination with the files that are stored on the server. However, customized pages store those changes to the files in the content database and are rendered from there. Now, this may not seem like much of a performance hit, and in many cases, it is slight, but it should still be a consideration when customizing. Along with this comes the risk when upgrading and patching. During the upgrade from 2003 to 2007, unghosted or customized pages caused issues, you had to re-ghost these pages before the upgrade would complete. I don’t know if this will be the case with upgrade to 2010 yet, but I would measure that risk carefully when considering customization. Also, many organizations use SPD to “brand” their SharePoint sites with their own logos and colors. Now, if this is done correctly, it should only be a slight risk for patching, but upgrading to the next version of SharePoint will break this and you will have to have a new branding solution ready for deployment when you upgrade. Remember, though you should never modify the 12 hive files to brand your site, these can be replaced at any time with patches, so this poses a definite risk! Customizing using custom code, usually Visual Studio and C# code, is the riskiest of the 3 methods. You are now generating your own code, using the object model, and affecting the way that SharePoint works. This is definitely a risk when upgrading and patching. You will have to test very thoroughly to make sure your code will still work after upgrade or patching. Administratively, this adds more overhead, and should be a definite consideration for customization. The best way to minimize this risk is to have any customization be packaged as a solution (.wsp file) before deployment. This will allow you to retract the solutions and even remove them if they are causing an issue with upgrade. The risk to performance is also greater with custom code. If your developer does not properly dispose of object (make them use spdisposecheck!) you can end up with memory leaks. Again, packaging as a solution allows you to easily retract the solution while your developer corrects any issues with performance as well. All in all, as long as you know the risks, and how to limit them, compensate for them, and recover if disaster strikes, customizing SharePoint is NOT a bad thing. You just have to know when to take that risk. Go ahead, be the gambler! 11/5/2009Vanity URLs have become a recurring theme for me. I have written several posts recently on them (here and here). So one more couldn’t hurt, right? They say things come in threes (at least with celebrity deaths, that holds true). With that said, here’s the most recent hurdle I’ve had to overcome with Vanity URLs. When you create a site collection with a vanity URL, you have a whole new checklist of things that you need to do to make sure the site works correctly. You have to make sure you add the site into the search scope so that it will be crawled, you have to make sure that your links are updated correctly, and if this will be a site for content deployment, your staging site must either be a top level site collection or another vanity URL. There’s one little thing I forgot when doing my most recent battle with a vanity URL. You see, when you create a vanity URL, you lose the ability to use alternate access mapping for that site collection. This is most especially important to consider when creating a public facing website using this method. I had created www.acquiredcompanyname.com as my vanity URL for a site collection. This was one of those companies that had been acquired, but needed to maintain its own identity. Once the site went live, all worked well, or so it seemed. A couple of days after deployment I suddenly started getting phone calls and emails stating “the site is down” and “I can’t get to the site, did you change something?” My immediate answer was “no” and I had to see what was going on. What I realized was happening was that users were now typing acquiredcompanyname.com instead of www.acquiredcompanyname.com. Only the “www” version was working properly. Here’s where a separate web application along with an Alternate Access Mapping comes in handy. Either version will “just work” with no problems. But in the case of site collections with vanity URLs, you have to do something else. I decided to set up a new site in IIS and redirect acquiredcompanyname.com to www.acquiredcompanyname.com. I won’t go into the details about the steps, Todd Klindt wrote a nice post about using that method to redirect to a site collection here. It includes the steps to create the redirect. I made those changes to both of my web front end servers, and automagically users could type in either address and be directed to the correct site! The end user will never know the wizardry that I used to make them happy! |
|
|
|
Lori Gowin
SharePoint Administrator
Lori is a SharePoint Administrator who has been working with SharePoint and InfoPath technologies for over 4 years. When not focusing on SharePoint, Lori unwinds watching sports and spending time with her husband and children. |
|
|
|
|