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...

I have struggle a bit with my preferred tool to understand where the profiling data is stored these days, as it has changed quite a bit from the initial release of the tool in version 6.0 SP3 (this dates by quite a bit now).

It started a few month ago when one of my customer had some issues. We noticed that clearing the profiler was very slow. Going at data rates of just a MiB per second.

I was trying to locate the buffer files, as the profiler versions early from 7.1 used to store the data in a zero-impact buffer file. But this was not yielding any results. I could see from the Windows folder some temp files being written but not much else.

It continued with another customer last week, and today whilst I was opening a 16GiB buffer file it all came clear. I started by cleaning up a local drive to have enough space to old the file and do a local import. After copying the full file at a rate of 375 Mbps (still it took ~10 minutes) I thought I had done most of the...

I have collected Symantec.pl.xml files since the beta in February 2009 and have a repository of 2.5 GiB of XML here at home. I am not devoting much time to the task to be completely honnest, as a shell script take care of verifying if a new file is available every 5 minutes.

I have also crafted a few (Linux) utilities to get some information out of the xml files. The first one was just a file cleaner that hanlded the task of clearing the pl.xml from any localisation. I never made much use of it, however it was of great help when I discussed with the product team improvments that later came to the prioduct listing and how the Symantec Install Manager handles it (first a compressed version of the file and then a langaue agnostic version). The second utility is still in use scrapes package related data from the xml, and crafts a mirror tree of the SolutionSam site. It even has the feature to copy MSI files to the correct location if they are in the same folder as the tool....

It seems to be the Package Server problem season for me [1].

Whilst trying to stabilise my customer environment so they can enjoy PXE 2.1 and OS deployment tasks I found that the two package servers have some issues accessing the deployment share... getting an access denied message (which leaves no doubt to the root cause of the error).

Package Server 2 is trying to download the drivers.manifest.txt file from Package Server 1 (fully synchronised - and freshly cleaned of .net 4.0 [1]). But all we where receiving there was an error 500 (application error).

Checking on PS1 the url provided to PS2 was effectively throwing an error, indicating that .Net could not read the web.config file in path "\\?\Deployment\...". This may look unfamiliar to most of us, but having spent a couple of hours it rang a bell immediately, as earlier attempts to synchronise PS2 threw similar errors, but locally (when the PS was attempting to copy a downloaded file to \\...