-Iwan- wrote:Oh my god, it would be much easier to integrate a new parameter (maybe /logsave?) then using the things that you posted.
If no parameter was entered, then %SystemRoot%\wsusofflineupdate.log will be used. As an admin account is needed to install the updates, there shoulb no access problem.
If you want to use another path and name for the log file, then normally you know, if have write access or not. If you have write access, then you can change the logfile parameters by using for example "/logsave x:\what\ever\%computername%.log".
Please, don't try to add code for something, that most WSUS OU users doesn't need. Let the program keep as simple as it is.
Thank you for the feedback about log files, but I was looking for feedback more on the network share support.
I think having the log files set like that is a good idea, and it's only five lines. It's not useful for just network shares, it's also handy for flash drives and local installs.
And regarding the "As an admin account is needed to install the updates, there shoulb no access problem" does this refer to UAC or the log files? For the log files, you might not be able to write them to the WSUSo log directory if the share was a read-only share, or if WSUSo is on a CD drive. For UAC, I've ran the update.cmd in the client folder without right-clicking and "Running as Administrator", and it just gives me a bunch of Access Denied errors. The UAC elevation VBS script should fix that problem.
As for adding code, I imagine most users of WSUSo are either large companies/entities (like school districts) or computer shops. Being able to run WSUSo off a network share is a lot more convenient than burning discs or copying it to a computer (especially with the new automatic update scripts). I've found code that should work for it without breaking support for other methods of installing.
**EDIT** I've made the changes on a local copy of WSUSo and sent it to the server. So far so good - it's mapped the drive and started updates without a single issue. We'll see if the automatic recall feature works. I did have to edit the UpdateGenerator.au3 code - for some reason, even after removing the section on network drives, it still grayed it out. It also gave me a popup asking if I was sure I wanted to enable it, which appears to be intended for Vista+. I'm using XP on both machines (Media Center and Pro). I think the code for determining the OS is broken. After removing not only the code checking for a network drive, I had to remove the code for the Vista+ check.
**EDIT2** As always, the code doesn't work on the first run.
Did not copy start-update.cmd properly (still need to figure this one out)
Did not make registry key (%REG_PATH% is not set in update.cmd of course)
start_update.cmd didn't set the WSUS_PATH variable properly (fixed)
Pushd doesn't work on restart - loses network share?
--When using a shortcut that tells CMD /K to keep windows open it works?
Need to delay start_update.cmd to make sure the network card has an IP address
--(fixed, ping 127.0.0.1 -n 15)
My main problem I'm trying to fix now is the pushd losing the network share. It will map the share fine, then switch to the share and the CMD folder, but when it does "start DoUpdate" the network drive is unmapped. I think I've figured that one out (I changed it so that the pushd command does %WSUS_PATH%\cmd and then just does "DoUpdate.cmd" instead of "start Doupdate") but I didn't get a chance to test it before I left work. I think what was happening is when a new window opened pushd does a popd (?). I found someone else that had the same type of problem (
http://itsupportcell.com/viewtopic.php?f=37&t=165 last post).
I'll test the tweaks tomorrow and see if I can get start_update to work, if I can't do it with pushd I may have to set it up so that update.cmd checks to see if the drive it's running from is a network drive, then change preparerecall so it changes depending on whether or not it's a local drive. Then I could use "net use" (which shouldn't lose the network map in the script) and not worry about it interfering with recall from a disk or local drive (because net use can't use local paths to map a drive). If I do that, then I'll probably use pushd in update.cmd (which works fine for some reason, doesn't have this issue with losing drives), and I think I can use WSUS_WORKING with "net use" to map it to the same drive as pushd (pushd maps to the last available drive letter; since a lot of companies use mapped drives, we don't want to interfere with any of those).