Announcer: The views expressed on the SharePoint Podshow by the hosts and the guests are their own opinions and do not represent the opinions and the policies of their respective companies or Microsoft. [music]
Nick Swan: Hello, and welcome to another episode of the SharePoint Podshow. I'm here with Brett Lonsdale begin_of_the_skype_highlighting end_of_the_skype_highlighting.
Brett Lonsdale begin_of_the_skype_highlighting end_of_the_skype_highlighting: Hey, how are you doing, Nick?
Nick: And Rob Foster begin_of_the_skype_highlighting end_of_the_skype_highlighting. I say Rob, but we've not got Rob with us. We've decided to replace Rob with a moldy banana. Because we've been in the Lightning Tools office in the UK, and we thought that Rob's been on too many intro shows and the intro's gone on too long, so we thought we'd replace him a banana. Banana Rob, how's it going? [silence]
Nick: Not got a lot to say, has he? [laughs] So, Brett, what's going on?
Brett: As you heard on the last show, I'm back in the UK. It's nice to come down and spend at least one day a week with you down here at the Lightning Tools office that we call Lightning Towers.
Nick: For anyone who's in Redding any time and fancies coming over for a cup of tea, you should look us up and pop on over, definitely.
Brett: So is it just tea, now, Nick? Or has anything changed recently?
Nick: No, I did have a bit of drink - I told Rob already, so he knows. I've been off drink. I didn't have any alcohol for eight months, and decided now's the time to start again. We're going to go for curry tonight, and a beer as well.
Brett: I know we do have the beer fridge in the kitchen, so we'll maybe stock that up soon, I guess. What news have you got regarding SharePoint?
Nick: We've just got to tell you about the Lightning Chat web part that we've today just put it on our website. So what we've been doing at Lightning Tools, because there's so much new stuff to look at in SharePoint 2010, we've kind of copied the 20% idea that Google have been doing, and some other companies, where everyone can take a Friday and just look at whatever they want to do and develop whatever product or work on whatever they want to do. We're starting to see some of these things comes through now that people have finished, and we're starting to put them on our website. The Silverlight chat part is something that works within SharePoint. It's a sandbox solution as well, so it's quite cool.
If you want to see what a sandbox tools is, you can download it, install it as a site collection administrator and deploy it to your site and use it to chat to other people who look at the SharePoint site as well. So take a look. It's quite cool. Try it out.
Brett: And I believe that's Silverlight. You can use the Silverlight component on its own as a client.
Nick: Yeah, yeah. It's Silverlight 3. You can right-click on it and install the component on the desktop. So it works like a Windows application, the Silverlight is running as a Windows application and you can us it outside of SharePoint. But we've realized that not everyone can install Silverlight on thier desktop because of corporate policies and whatever, so we've actually developed an Ajax web part as well, that works using the new SharePoint ECMA JavaScript library as well. So they can use Ajax chat web part, if they can't use the Silverlight one. It's cool. Check it out.
Brett: Excellent. We've had a few shows on SharePoint 2010 now, and there's still been strong interest in it. I've recently read that the launch date is finally here. The 12th of May, people are actually going to be able to get SharePoint 2010, the real version. It's going to RTM in April sometime, is that correct?
Nick: Yeah, I think so. They put a post on the SharePoint Team blog that the launch party is May the 12th, I think, isn't it? And RTM is going to be sometime in April. So hopefully that date won't be too late in April, and everyone will be clamoring for the download who's got access to an MSDN subscription or whatever. Whoever gets access to the download as soon as it RTMs. I can imagine the downloads will be quite slow, won't they, on that day. But we're certainly looking forward to it.
Brett: Excellent. Rob, the moldy banana, he can't really talk right now, so I'll intro his interview for him. He did an interview with Gary Lapointe some time ago, and has reshot the interview with Gary Lapointe recently, because he lost the interview, or at least half of it. So it was him talking.
Let's jump into that and listen to Gary Lapointe and Rob Foster begin_of_the_skype_highlighting end_of_the_skype_highlighting talk about the PowerShell in SharePoint 2010.
Rob Foster begin_of_the_skype_highlighting end_of_the_skype_highlighting: I'm here at with the MVP Summit 2010, with Gary Lapointe. We're sitting in the Microsoft Surface Lab here in Building 37, is that right? Yes, we're in Building 37 at the Microsoft campus in Redmond. Gary, I guess the first question we typically ask is who are you and how did you get into SharePoint?
Gary Lapointe: My name is Gary Lapointe. I've been working with SharePoint now since about May of 2007. So actually not too long compared to some of the others around here. I started out in a company out in Knoxville, Tennessee, doing an upgrade project from 2003 to 2007. I started writing reams of documentation about the configurations we had to do, lots of taxonomy kind of stuff, and realized that I really didn't like creating that documentation. [laughs]
So I started creating a bunch of code, STSADM extensions and whatnot, that we then used to actually run our upgrade. That was kind of my jump into SharePoint was through the initial creation of some of the STSADM extensions that I have out there.
Rob: That's something interesting. But before we get into that, I want to talk to you about yesterday. The SharePoint MVP event this year was going skiing, and you have probably one of the most amazing falling stories I've ever heard. [laughs] Do you want to elaborate on that?
Gary: [laughs] Do I? OK, so we went to Steven's Pass, and it was actually my second day skiing. I went with Jason Medero Monday to Crystal. It was kind of heavy, wet snow, and I'm used to nice, light snow out in Colorado. I was going down the hill, and one of my skis caught in the cement that we were skiing in and popped off. So I climbed about 30 feet back up to get that ski, went another 50 feet down afterwards and hit another patch of wet snow.
My pole, I basically just fell face-forward and poles got caught underneath my skis, so I couldn't move my arms, my hands. I ended up sliding face-first down the mountain at least 50 feet, until I finally stopped at the end of a hill.
Rob: I would have probably paid money to see that, but unfortunately I didn't make it up that high on the top of the mountain. [laughs] But actually I'm surprisingly - I know you live in Colorado, so you ski quite a bit and stuff. But being a Tennessee boy, I'm not really that sore. My butt is sore, and I hope that's from the skiing and not from rooming with Eric Shupps. [laughs]
But actually I'm feeling great. I'm surprised at how well it took off, and I had a good time.
Gary: Yeah, it was a lot of work skiing in that snow, though. I'm used to skiing hard blues, blacks, occasionally double black diamonds. But I'm not used to really, really heavy snow. It was a lot of work skiing through that. I can imagine somebody beginner doing it. It's not easy.
Rob: Yeah. I think I said something on the DL as we were planning this out, hey, I'm from Tennessee, I don't really ski unless it involves water, a boat, and/or a truck. [laughs] It was fun. It was fun to get out. I know you've done quite a lot, and I know a lot of our listeners do know you from the STSADM extensions and things.
Can you talk about how you got started with that, and some of the things that you do with that? Because a lot of people I don't anticipate are going to go immediately to 2010, and your stuff is going to be very valid for years coming on up. A couple of more years, three more years.
Can you talk about that and how you got started? What they are and just the rundown of them?
Gary: Yeah. And actually a lot of what I did will be applicable in 2010. I've started migrating some of that already. I'll talk about that a little later. As I mentioned earlier, I started out in this company in Knoxville, Tennessee, actually not too far from you. We had a fairly massive upgrade project, almost a thousand site collections.
A lot of what we wanted to do was not just upgrade to 2007, but really fix tons of issues we were having. Findability issues being the big one, security, lots of stuff. So what we had to do was not just upgrade the product, but really change everything. It was more of a migration, a complete rework of everything.
I basically spent about six months planning the upgrade, and a lot of that was through creating these customer STSADM extensions. STSADM is like a mainline tool, and it turns out it's extensible.
So you can, going through Visual Studio, implement a single interface, create and XML file, and you can create as many commands as you need to accomplish your needs. So out of the box it's about - I forget what the last count was. It's like 186 commands. So it's going to get you part of the way, but there's just a ton of things you can't achieve through the command line.
You can achieve some things through PowerShell, but you're writing a whole crap-load of code to do that. What I wanted was nice one-liners.
So if I want to create a web application, for instance, and make sure the path for that web application is set, I can't do that out of the box. So I created a one-liner command, it looks very similar to the extend VS command, but now I can set the path. I know where it's going to go so I can follow my corporate standards.
A lot of commands I've got just came out of needs that we had during that upgrade project, that I originally worked on. I left that company, though, and the company I was with basically allowed me to retain the rights to that code that I created so that I could continue working on it and release it to the community and whatnot.
And just over the years, working with various clients, my own individual needs, it just continued to keep going. I think I'm out about 145 commands right now. I've got a few PowerShell commandlets that I've created as well along with that.
And just within the past month or two, I've started migrating all those to SharePoint 2010. Most of them are still relevant. I've got right now probably about 25 of them migrated over. I'm hoping by RTM to have at least half of them migrated over.
Rob: What's your most popular top three of your STSADM extensions?
Gary: The most popular one is actually one of the first one's I created, which is converting the subsites to site collection. That one was a beast to create. With the taxonomy changes that we were doing, we had some site collections that were just massive, really, really large. What we wanted to do was pull those out into their own site collections. And if you've got a standard WSS site, it's not that bad. But once it's a publishing site, which all these were, it's just not possible out of the box. There's tons of issues that go wrong. You've got page layouts that get all screwed up. You master page gallery is disconnected. There's XML in hidden property bag fields that get all screwed up.
So I spent the better part of a month or two trying to figure out how to do that, how to achieve this goal, which was really critical to our particular project.
Again, that was one of the first ones that I created, but to create that, I had to create probably about 15 other commands to support it. So that one, every week I look at my stats, and every week it is the most hit blog post.
And then below that, I've got a few other commands that I've built, which were actually built to support that one main one, which are to export and import lists and list items. Those would be the other more popular ones.
A lot of these are just internally used in the content deployment API, which is littered with bugs. So my command is to try to get around some of the bugs. I use the out-of-the-box stuff as much as I can to do the import and the export as much as I can, and then I've got some stuff that will run to try to fix the stuff that import failed on and that kind of stuff.
There's a little bit of magic behind the scenes that I'm doing to try to repair some of the faults with the API. But, yeah, those every week hands-down are the most popular ones on the blog.
Rob: That's cool. That's actually good to know. It seems like one of your first ones was a common problem that a lot of people encounter.
Gary: Yeah. And going to 2010, I expect it's going to continue to be a problem. So when I set out to do the migration, I took that command and said, all right, what is it going to take to actually migrate this one over? And that's what I started with. The 25 or so that I've got migrated right now, with maybe the exception of two or three of them, were to support that one command. So that again, hopefully - I was hoping that a lot of the issue I encountered would be fixed by 2010, but they're actually all still there. [laughs]
Rob: I look at your STS80M commands and your PowerShell stuff as kind of like Lutz Roeder's .NET Reflector. That if you'd have charged a dollar for every one of them those, then you would not be working right now. [laughs] What do you think about community development? Because you haven't made a dime of this, you haven't made any money. But you've given such a great resource to the community.
I guess the question is around the people considering doing this, doing a community effort versus starting a company. Why put it out there for the community instead of starting a company?
Gary: There's a lot of reasons. For me, it's kind of win/win. One, there's a personal side of it, that I have taken a lot form the community -- the blog posts, forums, tools like Lutz Roeder and all that. This was my chance to give something back. So that was one of the original reasons why posted it out there. And once I started doing it and I realized how much feedback I was getting, that's what really encouraged me to continue doing it. Because what it does is really win/win. Because when I release something, it helps somebody out out there, they test it, they give me some feedback - "Hey, this worked great, " or "No, it didn't. I hit this scenario." And it's something I hadn't thought of.
And if I have the time, I can then go and incorporate that into the code and get that fixed, so the next time I need to use it with one of my other clients or whatever, now I've got that feedback incorporated and it's a better command.
So it's really win/win. The community benefits from the code, I benefit from the community's feedback. I get a better product and it makes me more effective as a consultant. And now I can also come in as a consultant and I have this tool at my disposal.
And not only do I have it, I'm intimate with it because I wrote it. I'm intimate with the problems that I encountered when building it. So it allows me to speak a lot more intelligently with the clients and help them out.
As far as being able to sell it as a company or whatever, now you've got to really be able to support it in a much more official capacity. In my case, if there is an issue, if I have the time to deal with it, I make every effort I can. But sometimes you're just slammed with work and you can't always get to it.
I do my best to respond to everybody's comments and incorporate fixes where I can, but I'm one person. So if I were to sell and form a company around it, then frankly I'd be overwhelmed.
Rob: It probably would kill the momentum as well. At that point it's a business, it's not personal.
Gary: Yeah. And to me, I really enjoy working on it. But when it gets to the point where it's something I have to do, I think that would take some of the joy out of it. I love the problems. SharePoint's a great product, and I love playing detective, solving bugs and figuring workarounds and whatnot. And SharePoint gives me lots of opportunities to do that. So building this product, it's been a good opportunity for me to be able to exercise those skills. And I have fun doing it. But when you get to the point where it's something you have to do and you have to maintain, and there's expectations for support and future versions and that kind of stuff, I think it takes some fun out of solving some of those problems and whatnot.
Rob: I guess now, with the ever-growing need for learning 2010, you're shifting your focus a little bit to PowerShell. What is PowerShell?
Gary: In a nutshell, PowerShell is a scripting language. The cool thing, though, is that it's object-based. So everything you're working with in PowerShell is a first-class .NET object. I can do something, for instance, like get a site collection, and what I get back is an actual SP site object that I can make updates to and commit back and whatnot.
With SharePoint 2010, I think we've got around 600 commandlets, which 2007, there was no out-of-the-box support for PowerShell. But you could use PowerShell to do quite a few things. But because there was no commandlets, you had to write a lot more plumbing code to do some basic stuff.
If you just needed to get an SP site object and manipulate it, that's not so bad. But if you wanted to do something like create a web application, like I said earlier, and set some of the properties that you can't do through the STSADM commands, now you're doing a lot more work. You've got probably 50 lines of code that you've got to write.
As an IT administrator who would need to do some of these tasks, typically they're not going to be writing code, they're not going to know how to manipulate the logic model and that kind of stuff.
So what you need, really, is a nice one-liner that I can go and call pass-up parameters that I want, and just have it work without having to figure out all the different logic and whatnot that's required.
With 2010 what's nice is I have all those commands. I have all those one-liners. I also have the commandlets that will give me the sort of more granular access to some of the objects. But what I can do now, is I can make much more complex scripts than what I could do with batch files, which is what was typically used with STSADMs.
Using batch files, conditional flow, and error handling and that kind of stuff, it's extremely difficult. Most people just don't bother with it, or they don't really know what they're doing. It's tough.
With PowerShell, though, I can just make my scripts much more elegant. A lot of the stuff I do, for instance, I create my scripts in such a way that I can drive them off of an XML file. So once my scripts are done and clean, I don't ever have to touch those scripts again, I just modify the values in my XML file and just point my script to that.
It becomes much more easy to take those scripts to different environments, different clients, whether it's production, test, dev, or whatever. Or as a consultant, different companies and whatnot. Modify a few values in your XML, and just run the script and you're good to go.
Rob: What tools are available to help you write these things? In theory, you can write them in Notepad. But are there any tools that are more advanced than notepad?
Gary: To start with, you've got the SharePoint Management Console, which is just a PowerShell console app. It's just like going into a DOS command prompt, but it's PowerShell. I will use that if I'm just trying to check quick properties or whatever, but if I need to actually write a script, something that I'm going to reuse multiple times, I've functions in it, that kind of stuff, I'm going to use something like that PowerShell integrated scripting environment or Power GUI, which is a free, open source product. There's a myriad of other commercial products and whatnot.
If you write it in that, it becomes a lot easier to debug, you get IntelliSense in some of them. The ISE, you don't get IntelliSense, but you can step through your code and see what's going on, set watches and that kind of stuff.
What I will typically do is set up my profile so that whenever I load any one of these editors all of the PowerShell commandlets are automatically loaded for me in memory. There's something called a SnapIn that gets loaded, and that way if I'm in the ISE or Power GUI or whatever, I immediately have access to all those commandlets without having to do anything special.
Rob: What's a typical good place to start learning it? Because it seems like the learning curve for developers is not that steep, but the learning curve for admins is going to be extremely steep. We talked about this a little bit before, but it seems like PowerShell in this instance, and in the way you can utilize it in SharePoint, is applicable to both devs and admins. How do you learn it?
Gary: The way I started actually is I just got a good book. There's at least one out there that's free that you can just read online. But the trick with PowerShell is that you've really got to know the object model to a degree. The syntax for PowerShell, it's a little kludgy. So even me as a developer, I do a lot of ITM and stuff, but my background is development. It took me a while to get used to PowerShell. And there's a lot of things that I kept wanting to do the C# way, and it either doesn't work or it's just not the most efficient or the best way to do it.
So in some cases IT admins who have never done any real coding might have an easier time picking up the syntax for PowerShell. Whereas developers who are wanting to do certain things are going to have potentially a more difficult time.
But developers are going to have the advantage that they're more likely to be familiar with the API and how to work with certain core objects within SharePoint.
What I really encourage people to do is, one, get a good book. If you can get on one PowerShell 2, definitely do that, versus 1. SharePoint 2010 will support both PowerShell one and 2, but it's a lot easier to write scripts in PowerShell 2. The error handling is better, you get things like modules which allow you to hide some things that you don't want people calling and that stuff. So it's much better to write your scripts to support PowerShell 2.
And then look at all the examples that are out there. I've got a few blog posts that I've done on how to script, for instance, for farm creations. How to set up a farm, how to create your web applications and site collections, how to set up you site applications.
Zach Rosenfield, who's on the product team, has got a great blog with some really good SharePoint examples and whatnot.
I personally learn better through examples. So I'll scour the web, look at blogs, what are people doing, how are they scripting this particular task. Maybe there's something similar to what you want to do and whatnot. Start from there, and then use the book to just help you with core syntax. How do I declare a variable? How do I do four loops. That kind of stuff.
Rob: I guess PowerShell, we've talked about the development and things like that. But what about deployment? How do you deploy these things out? Is it just a file you run? What is the deployment scenario look like?
Gary: If you're just writing scripts, it's basically a file. It's a text file. You could author it in Notepad, like you said. A deployment there, you can just copy it to your server and run it. You can use remoting with PowerShell, so I could actually be on my workstation PC, and if I set up and enable remote - and there's a couple of things I need to do for that. But I could basically run scripts against my server without having to log into my server. So there's some really cool possibilities there as far as not having to go out and have physical access to the server.
There's also some things you can do with modules, where you can register a module and make those available. But effectively, it's just a text file.
When you get into creating customer commandlets - so if you've looked at availability of commandlets out of the box and whatever might be available through third parties out of my stuff or otherwise, and you're not finding what you need, sometimes you get to the point where you need to create a custom commandlet. Usually for building block type stuff.
For instance, out of the box there's nothing to retrieve and SB list object directly. You can get to it through the get SB web, but if you just have an URL to a list and you want to get and SB list object, there's nothing out of the box to do that.
I built a commandlet that will do that for me. It's just a real simplified example, but you can take that in a lot of different directions.
From there, you would basically just go into Visual Studio 2010, and you can build a custom commandlet and deploy it just like any other WSP, any other SharePoint solution package.
In the past if you wanted to create a custom commandlet, you had to create your own snapin, for 2007 and whatnot. Which was fairly difficult, because you not only had to create the installer for the snapin and the setup package and whatnot, but if you had to go to a 64-bit environment, you're going to have to do some hacking of the MSI in order to get it to run in 64-bit. Unless you're using like a third-party installer.
But if you're just using what Visual Studio provides, there's a ton of issues that you end up running into that you've got to solve in order to make that happen.
With 2010, it's much easier. Aside from the logic of the commandlet itself, I can create and deploy a commandlet within probably about two or three minutes. There's an XML file that you've got to set up, and you can basically jut look at the existing commandlets that have been deployed to see what the schema looks like and copy and paste, basically.
And then you create your classes, implement a specific base class, and then you're just going to use 2010's package and deployment features to send it out.
Rob: It sound fairly straightforward, specifically with the new tools that are available.
Gary: Yeah. The 2010, I really love what they've done with the packaging stuff. It's a much better development story then what we had in 2007.
Rob: What's your favorite feature of 2010?
Gary: Visual Studio or SharePoint?
Rob: Let's say SharePoint at this time.
Gary: I actually like the services application piece, the architecture changes there. I was never a fan of the shared services provider. It was kludgy.
Rob: A single point of failure.
Gary: Yeah, a single point of failure. And if I want to host an Internet site or an intranet site, or if I need different profiles, I've got to duplicate all these other services and stuff. It was just a maintenance nightmare. It was just way too many issues. With yanking that out and now making my services so I can target and associate it with different web applications. I can have multiple instances of, for instance, for my search serving different needs, serving different web applications and whatnot.
To me, that's really the game changer for SharePoint, because it's going to open the door to a lot of enterprise installations, specifically, that have lot of issues with the SSPs.
Rob: Yeah. And I think that's not really NDA at this point, but it's a theme that we saw in one of the sessions we were in at Summit. It was basically to just scale out. You can scale out, scale out, scale out, all these different tiers. I think that's such a beautiful thing.
Gary: Yeah. The only problem I have with it, right now at least, is that there's so much that you can do, you're somewhat limited to what you can do through central admin with configuring those service applications. So the best practice when you configure them is to go down and do it through PowerShell. Which is great, because you can automate it. The problem is, some of the service applications are extremely complex to configure through PowerShell.
Most of them are fairly straightforward, but when you look at something, for instance, like enterprise search, my script which configures that is close to 300 lines of PowerShell code.
If you compare that to STSADM with 2007, to start search you had maybe one or two lines of STSADM to start search. So if you follow the best practices and you basically do it right, you're looking to have to write a lot of PowerShell code to make that happen.
Or you can just to go my blog and copy it off there and you're good to go. [laughs]
Rob: That's cool, that's cool. What about Visual Studio? Obviously you've been in that for quite a while. What do you like about what you see in Visual Studio 2010?
Gary: The main thing right now is just the packaging capabilities. With a lot of the clients that I work with, we try to avoid our project files themselves having any kind of third-party dependencies. So in the past I used to use tools like WSP Builder and SPS Dev and whatnot. But I didn't always like that because it requires what version of those tools do you have, and does it support this or that?
The fact that I can release my code to a client and they don't have to have any other tools downloaded in order to be able to deploy and compile that is something I really like.
And then the fact that within that framework I can go and make changes. I can override some of the default behavior, if you will, change the solution manifest and stuff like that. The fact that it's not entirely black box.
If you're kind of novice, you don't really know what's going on, sometimes black box is good. But once you get to the point where you really know what you're doing, you can unlift the covers and actually get in there and tweak things. I like that.
Rob: Yeah, yeah. They brought it home with this one. Have you seen any of the code spike solutions that are springing up around Visual Studios 2010, the SharePoint tools?
Gary: Honestly, I haven't had time to really look at them.
Rob: I thought there's no way that anybody's going to spring up anything that's going to beat this, but they're really extending it quite nicely. Things like adding a SharePoint tab to your references, to where you can have all the DLLs right there. There are some interesting community efforts going on around Visual Studio 2010 that I'm finding interesting. Not necessarily bringing it home, but more helping complete the picture.
Gary: Yeah. I've seen a couple where you can go in and configure the steps that occur when you do a build basically: package, reset, IS, that kind of stuff. I've seen a few that basically extend that. Run a PowerShell script, for instance. Or do an XCOPY instead of an actual package deployment, that type of stuff. So, yeah, just that. The fact that I can go ahead and extend those steps and add whatever I need to it. That's pretty cool.
Rob: Do you have anything else you want to leave with us? Any knowledge or suggestions? How about where can people find your blog?
Gary: You go to STSAMD.blogspot.com. I'm guessing I'm probably going to have to change that. Actually with the 2010 stuff I'm doing, I wasn't originally going to, but I decided to go ahead and keep the STSADM interface to the code. So if you do have scripts using some of my stuff, they will still work for the most part in 2010, hitting STSADM. But honestly, if you're going to be successful with SharePoint 2010, you've really got to learn PowerShell. I would definitely encourage that.
The other thing, there's some things to watch out for when you're looking at PowerShell, particularly when it comes to threading and whatnot. There's some really interesting side effects, if you will, with the disposal pattern when you get into PowerShell. So watch out for that.
There's a few blog posts out there. Zach Rosenfield has a couple posts there, and I've got some on my blog as well, that kind of go a little deeper into that.
Rob: Do you have a Twitter account or email address you want people to shoot your questions? Or can they just contact you through your blog?
Gary: Yeah, there's a contact link on my blog. I'm also on Twitter. It's just @glapointe. I try to be pretty good about responding to comments on my blog, but sometimes I get 20 or 30 a day, so I'm not always on top of all of them. But usually I can get back to people within the day.
Rob: Cool. Gary, we thank you a lot for sitting down with us and talking with us. This PowerShell thing is really interesting to me. I'm looking forward to seeing how it plays out, and definitely watching the story happen on your blog. [laughs] I frequent it a lot. Anyway, I guess we'll close down the interview. Thanks for talking to us. We look forward to seeing you at the rest of the Summit.
Gary: Yeah, thanks for having me. It was fun begin here.
Nick: Thanks so much, Gary, for doing that interview. Sorry you had to do it again. Apparently the second time was better than the first time though, so you got to have two cracks at it. That what was according to Rob, who was trying to make amends, I think, for having lost the first one. But thanks for taking the time out of your schedule to do that.
If anybody's got any questions or feedback, feel free to send us an email at feedback@sharepointpodshow.com.
We'll have some more shows coming up soon. I think we'll try to get back to a regular two-week schedule for pushing shows out. I know we're a bit lax with Rob losing recordings and the moldy banana not being very quick at mixing in, and stuff like that.
We're cracking the whip on him now and we'll make sure we get some more out soon. Cheers, Brett!
Brett: Thanks a lot, Nick.