This week was pretty much replication week for me.
I'll cover a few topics on this blog but today we will look at the Package Replication part and the implications it has for UNC base packages.
When a SMP is refreshing it software packages it does a few check that relate to the package source type, as they are handle differently: local, unc or http sources.
It also verifies whether the package is local or replicated from another server. In the later case, and for UNC package the refresh will no generate any snapshot nor any codebases for the server.
One of the cases this week came a partner had tested successfully the following scenario in their lab: Server A is the master SMP and replicates (via standalone replication) a set of DSL packages (thus UNC based) to Server B (and other 'slave' SMP's). Packages from Server B where able to download the DSL packages without any problems.
But as per the package snapshot and codebase generation process summarised above the slave SMP (Server B) had no codebases for the replicated packages. So we needn't to know how the PS had downloaded the packages and why the same setup in production failed, with the slave PS constantly waiting to download the replicated packages...
We started on the test systems, and found that the Package Servers from Server B had received codebases from Server A (the master) pointing to one of the master Package Servers.
The codebases had been server from Server B though, so the GetPackageInfo request did redirect the PS to the parent server where download sources (codebases) would be available.
With that information available I could track down the method used to redirect the client to the parent and check the conditions to implement the redirect. However this did not tell us exactly why the redirection wasn't taking place in the production environment.
So we ended the week with a last webex (I think I blew my record with 15 remote session in this crazy week) on the customer server. I'll spare you with the tedious code review needed but we got to a point were it was all down to the SiteSubnet cache. So we checked on the SQL which sites and subnet the Server B PS was a member off and found that it was in no sites at all.
We created a single site to which we assigned the SMP and PS subnets. As this was done we refreshed the browser window we had opened to GetPackageInfo.aspx for troubleshooting and tada, Server B sent us a http response 303 that send us to Server A and provided us with valid codebases.
To wrap this up, let's just say that your site management configuration should take care of the Package Servers as well the clients!