[wpkg-users] how to safely copy wpkg.xml to a central UNC location when using Wpkg Agent (for after-processing with wpkgCreateReport)

[Malte Starostik]

Hello Urs,

Am Donnerstag, 26. Januar 2012, 14:04:12 schrieb Urs Rau (UK):
> I am probably missing the tree for the forrest on this one. It seems so
> easy and even the product docs for wpkgCreateReport says under point 2.2
> 
> 
>  1.  Prerequisites
> 
> <cut some>
> 
> The prerequisite is that you have copied the wpkg.xml file of every client
> to a central directory, carrying the name of the computer it originates
> from. This can easily be achieved by appending something like the
> following command line at the end of the script file you are calling wpkg
> from.
> 
> copy /Y "%windir%\system32\wpkg.xml"
> “%wpkgshare%\clientStates\%computername%.xml"
> 
> I can see how this is easily achieved in a deployment where a batch file
> calls up wpkg.js processing, one adds it just after cscript has finished
> executing wpkg.js and returns.
> 
> But how do you practically do it when using the wpkg agent, which is a
> service that does not really finish or return in that sense ? It seems
> that anything I try to do from it finds the wpkg.xml locked because the
> wpkg agent is currently processing it. Doohh!
> 
> There must be an embarrassingly easy answer to this, surely?
> 
> Thanks for pointing out what must be really "obvious" to most.

assuming agent == service, that service itself does not lock the file.  If 
anything does, it's wpkg.js.  Thus, if you configure the service to execute a 
batch file containing the above as a post-execute script, you should be all 
set.  One problem might be lack of write permissions on the file server e.g. if 
the service is running as SYSTEM.  If you have an AD infrastructure, you'd 
only need to grant write permissions to the Domain Computers group.  Without 
an AD, you need to either allow anonymous writes :-o or better have the batch 
run net use ... before copying.

I haven't used the service in a while though, since we switched to WPKG-gp.  
There we just call some wrapper.js instead of wpkg.js (wrapper.js calls 
wpkg.js and then copies wpkg.xml to a server among other things).  We handle 
both read access to the repo as well as write access to the log file / wpkg.xml 
storage via the machine account (with an AD) and a Samba server on the other 
end where the log dir has the sticky bit set so only the machine that first 
created a log/status file will be able to overwrite it.  Works great.

Cheers,
Malte