In this article I would like to give you some information about a very important timer job in SharePoint 2010 - the Application Addresses Refresh Job. If you do not understand what it is used for you might see some strange (to you) error messages when configuring SharePoint. Even if you're familiar with it it might be a good idea to continue reading.
Purpose of the Application Addresses Refresh Job
The Application Addresses Refresh Job has one specific job to do - keep track of all available and online instances of all service application end-points. This means that whenever a proxy requests an endpoint for a service application it will ask the Topology Service (the Application Discovery and Load Balancer Service) for an endpoint. The Topology Service keeps a list of the endpoints that has been discovered by the Application Addresses Refresh Job and passes on one of these endpoints to the proxy, using the load balancing algorithm, which uses that endpoint to talk to the service application. So far so good...
So, what could go wrong here...
The problem is that this job only runs (by default) every 15 minutes. And unless you follow the first rule of Spence - "Step away from the keyboard", you will experience some interesting side effects.
Service Application configuration
One of the first times you'll experience this 15 minute delays is when creating Service Applications in SharePoint 2010. Let's take the Secure Store as an example. You create the Secure Store Service Application and trigger happy as you are you click on it to configure the Secure Store Key. And most of the times you will see an error like this:
You hit the reload button a couple of times, starts to fiddle with permissions but nothing happens. Finally you realize - ahh, I haven't started the Service Instance of the Secure Store, so you start that and head back to the Secure Store Service App to continue to configure it. But, you still receive the same error message. You do some more fiddling with permissions etc until your totally lost in your configuration madness. You do some Binging on the Interwebs and suddenly it just works...
What really happened was that the Application Addresses Refresh Job run, meanwhile you were furiously blaming the product group for a crappy product, and found a valid and working endpoint for the Secure Store Service App. And now the Topology Service are aware of the endpoint and can pass it on to the proxy.
What you really should have done is; first start the Service Instance, then create the Service Application. And if you still get the error message, manually kicking off the timer job will do the trick.
Another common scenario where similar results may be seen is when you do some farm reconfiguring; such as adding/removing/rebooting servers, moving Service Application Instances from one server to another (stop on one server and start on another). You could do this while your farm is hot and running but make sure to start the timer job whenever you do a change (start/stop and instance or add/remove a server). Worst case your end-users will be unable to use the Service Application for at the most 15 minutes. One scenario where I've seen it happen is when you take a server out of the load balancer rotation to do Windows patching and then you need to reboot that server - the service application will be unavailable for that time on that machine (duh!). So if you have for instance three servers running this service instance, every third (Round Robin) request will fail. Running the timer job immediately after starting the re-boot sequence will mitigate any errors.
Should I change the Timer Job schedule?
Well, this is totally up to you. From what I've seen it's not a "heavy" job and you could lower the interval. But under normal circumstances 15 minutes should do the trick. But when doing maintenance, as discussed above, lowering the interval might be a good idea.
A short, and pretty intuitive, post about a very, very important Timer Job in SharePoint 2010 - the Application Addresses Refresh Job. Make sure that this job is running and behaving - otherwise your end-users (and proxies) will not be able to talk to the service application instances.
[Update 2012-05-20] If you are interested in more details on the topology web service and the service application load balancing I recommend that you read the following post by Josh Gavant: How I learned to Stop Worrying and Love the SharePoint Topology Service.
It’s been almost a week since the International SharePoint Conference ended, the first of its kind – and what a conference it was!
I was honored to be part of the developer track, together with top-notch speakers and developers such as Andrew Connell, Ben Robb, Eric Schupps, Matthew McDermott, Mirjam van Olst, Paul Schaeflein, Todd Carter and Waldek Mastykarz. We’ve been working together on this “project” for a couple of months having weekly calls trying to build a solution that we would use for the developer track. I really think that we did a good job and that we covered a lot of the important pieces in a SharePoint project – that normally isn’t covered on conferences. And I do hope that you who attended it, enjoyed the track and what we tried to show you.
Everything that we built and presented is available for download. We’ve created a CodePlex project where we have uploaded the functional specs, all the session demos and the final solutions demoed. Go grab the stuff here: http://spkbase.codeplex.com. And if you have any comments or questions – use the CodePlex discussion features and let the discussion start.
Waldek and I started the dev track by building a couple of Visual Studio Extensions. After some initial problems with the Visual Studio Gallery site we finally got them published. Just search for “ISC” in the Extension Manager. And if you wait just a couple of more days – all this will be integrated into CKS:Dev.
Next year, our amazing host Steve Smith, will host the SharePoint Evolution Conference 2013. I would not miss it for the world!