From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!

1. Rename the wsp file to a .cab file
2. Open up the .cab file (used to be wsp) in WinZIP or something that can open a CAB file.
3. You can either: a)  extract all files in the cab file and open up the extracted manifest.xml; or b) look for manifest.xml in WinZIP and just extract that one single file.
4. Open up manifest.xml in notepad, Internet Explorer, or your preferred XML file viewer.

That’s it!

Several of my upcoming posts will be on how to create solution packages. Stay tuned!

I’m not sure if the crash took out IT resources (such as servers) for the IRS. I couldn’t help but think, “If the crash took out IRS servers, were they able to recover in a timely fashion”? Yeah I know it’s geeky and nerdy to be thinking about these things but I’m an IT pro—I can’t help but ponder these things!

Every IT resource—infrastructure and systems alike—should have a disaster/recovery plan. Within government agencies, they like to call this Continuity of Operations Planning or COOP. COOP is pretty comprehensive and includes not just how to recover IT but also how management succession, crisis procedures, etc. If you are part of IT and you get detailed to participate in COOP planning, most of your contributions to this COOP plan will revolve around recovering IT assets such as servers, applications, databases, and the like,

I can’t remember how many times I’ve seen network and DB administrators claim “yeah we have backups” and when disaster comes, the backups were no good and couldn’t be restored! What good is that??! What the hell is that?? See, it’s not enough that you are backing up data and applications; you must also rehearse recovery procedures using the capture back-ups so that you can confidently report to your management, “Yes, we have backups and can recover in the event of a disaster.”

In the SharePoint world, it’s not enough that you are backing up content and configuration databases—you should rehearse recovery procedures from time to time. How do you know you can recover a toasted SharePoint farm configuration if you’ve never rehearsed it and seen with your own two eyes that your backups are good? You must test your recovery procedures.

How often should you backup and test recovery procedures? Well, one can probably write a dedicated Web site just on the topic of disaster-recovery (just google it and there are tons). So, without having to discuss this too much, as a general guide I like to follow, the more critical your systems, the more backups and test-recovery procedures you should do. For less-critical apps, your frequency doesn’t have to be as extensive (the important thing is you do it). Just as an example, for critical apps—daily full back-ups with incremental back-ups during the day and test recovery procedures every 2 weeks. The “least frequent” backup schedule I’ve ever done for a “non-critical” app is bi-weekly full backups and test recoveries every 3 months.

The point is, you must backup and be ready to recover when disaster strikes. Nine years ago, the terrorists attacked WTC and the Pentagon. Last week, some lunatic had a personal grudge against the government. Who knows, maybe this week, some admin at your office spills some latte on your production server and toasts mission-critical apps. Whatever the disaster may be, be ready.

It was full day of sessions, networking, and bagels and pizza and coffee. It started with a General Session: The State of SharePoint session by Joel Oleson, NS Rana, Thomas Vander Wal, and Errin O’ Connor. From that point on, people branched to End User, Developer, Administration, or Special Interest sessions.

I’m primarily a solutions developer. A friend of mine who I bumped into at the conference asked me “so, are you headed over to the Developer sessions?” Initially, yes—my first session for the day was a developer session. But I mixed it up for the rest of the day since there were so many interesting topics and I like diversifying what I learn.

Here are the sessions that I attended this last Saturday:

• Building and deploying custom SharePoint Application pages (layouts) with Visual Studio 2008 by Michael Lotter
• Social Computing and Blogging with SharePoint by Dan Lewis
• Visually Developing Custom Web Parts by Becky Isserman
• SharePoint Admin Fundamentals by Joel Oleson
• Implementing a SharePoint Pilot: An IT Manager’s Perspective by Jonathan Distler
• Using the SharePoint Platform to Build Vertical Business Applications by Paul Galvin
• SmartCard Authentication: Considerations, Options and Pitfalls by Dan Usher and Joel Ward

I really enjoyed the SharePoint Saturday. I highly recommend that fellow tech professionals go to these events—they’re informational and you get the chance to network with other professionals (and gurus) in the industry. For me, the best thing I got out of SharePoint Saturday are product ideas that I may develop for Zenpo Software Innovations, LLC, my company.

I will follow up by writing individual entries for each session I attended.

Items discussed in the meeting:

• SharePoint Designer is now free – Wow! I couldn’t believe it! Check this out: http://office.microsoft.com/en-us/sharepointdesigner/FX100487631033.aspx?ofcresset=1
• Certification paths in SharePoint – MCTS Exam 70-542, 70-630, 70-541, and 70-631. All these exams use case-study type exams. So, the recommendation of those who have taken the exam is to get real-world hands-on experience
• There is a “Certified Master” for SharePoint. If you get this certification, you pretty much are considered all-knowing with everything related to SharePoint. For details, see http://www.microsoft.com/learning/mcp/master/SharePoint/default.mspx

It’s been a while since I’ve met with others that share the same or similar interest with a given technology. The information sharing and networking benefits of going to these events are great. There are things that you would otherwise miss because it’s difficult to keep tabs on everything going on in tech. Also, with today’s challenging economy, you should go out there and network. I recommend you find meetup at your hometown. If there is none, perhaps it’s time you start your own and lead the way.