June 2009 - Posts
This one’s for you @SteveHolstad!
I was helping one of our teams ease the deployment of a Silverlight project into various server environments. The project contained a ServiceReferences.ClientConfig file to reference some WCF services in the solution. When deploying the project to a Development, Staging, or Production environment, the team had to:
- Un-XAP the Silverlight XAP
- Copy in an environment specific ServiceReferences.ClientConfig file (or edit)
- Re-XAP the Silverlight XAP
Here’s how to do this pretty easily with TFS Team Build.
I like to store environment specific settings in the source control branch that corresponds to that environment. In the Dev branch (which translates to our Development Integration environment), I created a version of ServiceReferences.ClientConfig with the appropriate environment specific service bindings and placed it at. $\MyTeamProject\Dev\Env\Config\Services\ServiceReferences.ClientConfig.
In the Team Project’s build definition, you can now tap into the BeforeCompile target and do the following:
<Target Name="BeforeCompile">
<CreateItem Include="$(SolutionRoot)\Env\Config\Services\ServiceReferences.ClientConfig">
<Output ItemName="ServiceReferences" TaskParameter="Include"/>
</CreateItem>
<Copy SourceFiles="@(ServiceReferences)"
DestinationFolder="$(SolutionRoot)\Source\MySilverlightProject"
OverwriteReadOnlyFiles="True"/>
</Target>
The first thing that a Team Build does is get the latest code from source control, and place it in a working directory on the build agent. The new BeforeCompile target replaces the ServiceReferences.ClientConfig in the working directory with the environment specific one.
And it does it BEFORE COMPILE! When TFS then compiles the MySilverlightProject project, the resulting XAP will contain the environment specific version of ServiceReferences.ClientConfig.
This of course assumes that you’re structured your source control in such a way where you can point different Team Build definitions at different branches or directories in your source tree.
This probably falls under SharePoint Administration 101, but as a developer, I was pleasantly surprised at how easy it was to move our MOSS 2007 intranet to a new web front end.
Our environment is very simple: 1 SharePoint WFE and a separate SQL Server which is shared by several other applications. Our old WFE recently started acting up and we figured that we better get a new server up and running before this one GPF’d. It also ran a 32-bit version of Windows Server 2003, and we wanted to upgrade to Windows Server 2008 x64.
It was also important for us to not have to do any DNS changes. If that doesn’t work for you, you’ll have to adjust these instructions slightly.
The whole process was pretty simple, here are the steps I followed:
- Install Windows 2008 Server x64 on the new server
- Install MOSS but do not run the SharePoint Products and Technologies Configuration Wizard
- Bring up the new server to the same patch level as the farm
- In this case, I took the opportunity to bring everything up to SP2
- Run the SharePoint Products and Technologies Configuration Wizard on the new server
- Connect the server to the farm
- Host the Central Administration site on the server
- Let the wizard do its thing
At this point, you have a another fully functioning WFE in your farm. However, it won’t be able to serve any requests because as far as DNS is concerned, it doesn’t exist. You can browse to your site at the server’s IP address to make sure that everything is working.
- Send a nice email to your users to let them know that the farm will be down while you do this
- Run the SharePoint Products and Technologies Configuration Wizard on the old server
- Disconnect the server from the farm
- Change the old server’s IP address to something else
Your farm is now inaccessible until you assign the old server’s IP address to the new server.
- Assign the old server’s IP address to the new server
- Install your SSL certificate (if applicable) on the new server
- Set your host headers in IIS on the new server
That’s it! Go through Central Administration and make sure all your services are started, you should be good to go.
A couple of interesting things I learned while doing this:
- Don’t know why you’d want to do this, but it looks like your WFEs can be running different version of Windows Server
- You have to apply your host headers manually in IIS. Not surprising because the wizard probably has no clue what you have going on for DNS and load balancing.
Now I need to work on getting Windows Rights Management Services off the old server!
SharePoint Saturday Chicago was this past Saturday, June 13th at the Tribune Tower in Chicago.
Kudos to Kris Wagner and the rest of the organizing committee for pulling off a great event, I’m already looking forward to next year.
My session was titled: Building Public Facing SharePoint Sites. Using a SharePoint publishing site that I built out for the presentation, I went over the following:
- Publishing workflow
- Topology of the solution
- Tips for organizing your Visual Studio solutions
- Using publishing site definitions
- Packaging your run-once assets
- Configuring and running content deployment
- Setting up anonymous access
- Special considerations for public sites
As promised, here is my presentation, and the complete source code for the publishing site that I demo’d.
There was some great discussion, it was helpful to hear about the experiences of other people working on SharePoint publishing sites – it was comforting to see that we all also suffered over the same issues!
I recently took on the role of INETA User Group Mentor for Illinois, Wisconsin, and Indiana. As a user group mentor, my responsibilities include being the groups’ primary INETA contact, as well as being among the first to hear about exciting programs coming out of INETA.
INETA recently announced the Regional Speakers Program to help formalize the process around identifying local speakers.
Some excerpts from the announcement:
This new initiative is designed to help user groups coordinate speaking engagements for meetings and community events such as code camps connect with local and regional speakers. Long term, we (INETA) hope to use this as a staging ground to evaluate regional speakers for the national Speakers Bureau. The first phase of the program, registering speakers and connecting user groups with Regional Speakers, is now available.
We invite you to register as a Regional Speaker on the INETA web site and enroll in the program. The registration is open to all, so please feel free to forward.
User Group leaders are encouraged to search for regional speakers and contact them directly via the website. The link will launch a peer-to-peer email conversation for you to make appropriate arrangements. The program is designed such that a user group could potentially schedule all of its speakers.
If you’re looking for the definitive reference for programming against Microsoft Office Communications Server 2007 R2, be sure to check out Programming for Unified Communications with Microsoft® Office Communications Server 2007 R2, published by Microsoft Press and now available at your favorite retailer of books!
Go get it at Amazon.com.
I helped one of the authors – Chris Mayo – review his chapters on programming against the Office Communicator SDK, so I’ve seen first hand the quality of the content in the book.
Chris will soon be publishing a code library that encapsulates the Office Communicator SDK and extends it to enable you to build Contextual Collaboration functionality into your UC-enabled applications. I’ll be sure to write about it when it becomes available.