Network share support

[HowTo] Offline Update from a Network Share

Postby BrentNewland » 15.04.2010, 18:30

We're using this program over the network to install updates on machines we repair. We keep the updates in a folder called "updates" on a shared folder "bench-3" on the server "casbench3" (so change accordingly).

update.cmd
Code: Select all
@ECHO OFF
net use Z: \\CASBENCH3\BENCH-3
Z:
cd Z:\updates\cmd
start DoUpdate %*


.\cmd\DoUpdate.cmd
Code: Select all
At very end of file:

net use z: /delete
if "%REBOOT_REQUIRED%"=="1" exit /b 3010
endlocal



Have had no problems, although the program doesn't install very many updates at one time.
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Re: [HowTo] Offline Update from a Network Share

Postby AnonymousHero » 16.04.2010, 06:14

The method I've been using is this:

offlineupdate.cmd:
Code: Select all
@echo off

pushd \\install\offlineupdate
cmd /c cmd\DoUpdate.cmd /nobackup
popd \\install\offlineupdate
AnonymousHero
 

Re: [HowTo] Offline Update from a Network Share

Postby WSUSUpdateAdmin » 24.04.2010, 20:38

Thank you both! :)
RTW
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38

Network share support

Postby BrentNewland » 12.05.2010, 03:00

Network share support is something I desperately need due to the environment I'm using WSUSo in. Unfortunately, I can't make changes to WSUSo every time I update it. So, I'd like to help the WSUSo team get it working.

I've been doing some heavy research, and I think I've got some code which will work.


**edit** Updated with mostly working code - UpdateInstaller.exe is not compatible yet
client\Update.cmd:
Code: Select all
@echo off
set WSUS_PATH=%~dp0
REG DELETE "HKLM\SOFTWARE\WSUS" /va /f >nul 2>&1
REG ADD HKLM\SOFTWARE\WSUS /v WSUS_PATH /t REG_SZ /d %WSUS_PATH% /F >nul 2>&1
pushd %~dp0\cmd
set WSUS_WORKING=%cd%
DoUpdate.cmd %*


client\cmd\start_update.cmd:
Code: Select all
ping 127.0.0.1 -n 15
FOR /F "tokens=2* delims=    " %%A IN ('REG QUERY "HKLM\Software\WSUS" /v WSUS_PATH') DO SET WSUS_PATH=%%B
pushd %WSUS_PATH%\cmd
start DoUpdate.cmd


In PrepareRecall.cmd:
Code: Select all
  echo %DATE% %TIME% - Info: Registered recall >>%UPDATE_LOGFILE%
(add below) mkdir %SYSTEMDRIVE%\temp\wsus\
(add below) copy /Y %WSUS_WORKING%\start_update.cmd %SYSTEMDRIVE%\temp\wsus\

I would also change all references of %SYSTEMROOT%\ to %SYSTEMDRIVE%\temp\wsus\


In CleanupRecall.cmd:

Code: Select all
  echo %DATE% %TIME% - Info: Unregistered recall >>%UPDATE_LOGFILE%
(add below) [b]%REG_PATH% DELETE HKLM\SOFTWARE\WSUS /f >nul 2>&1[/b]

  %REG_PATH% ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v DeleteWSUSUpdateAdminProfile /t REG_SZ /d "cmd /c rd /S /Q \"%USERPROFILE%\"" >nul 2>&1
  echo %DATE% %TIME% - Info: Registered erasing of WSUSUpdateAdmin profile >>%UPDATE_LOGFILE%
(add below) [b]%REG_PATH% ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce /v DeleteWSUSTemp /t REG_SZ /d "cmd /c rd /S /Q \"%SYSTEMDRIVE%\\temp\\wsus\"" >nul 2>&[/b]




I haven't tested much of it, but I think that the code (with maybe a tweak here and there) should be able to work for either local or network paths, it should work with recall, and it should clean up after itself. I can fully test it tomorrow.




*edit* I recall that under Vista and 7 with UAC turned on WSUSo didn't work unless you right-clicked and chose "Run as Administrator". Well, I came across that problem in a previous project and I modified a script to elevate the command prompt (so when you double-click on the .cmd or .bat file it will pop up a UAC window then run the script and all sub-scripts elevated. I also made another script which disables UAC. Once I find them (have google desktop indexing my hard drives right now because I don't remember where it is) I can post them with instructions on integrating them into WSUSo. That should make it a little more user friendly.

*edit2* I may or may not still have the files I was looking for, I might have them at work, or Google Desktop might pick them up after I installed an add-on that searches inside rar files. If I can't find it, here's what I based that work on:
http://technet.microsoft.com/en-us/maga ... ation.aspx
Right near the top, there's a link to http://download.microsoft.com/download/ ... 008_06.exe
I used the elevate.cmd and elevate.js
I also referred to the older version of the article http://technet.microsoft.com/en-us/maga ... light.aspx
I recall it being a decent amount of work, but I did get it to eventually work automatically and transparently.
Last edited by BrentNewland on 14.05.2010, 00:05, edited 2 times in total.
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Re: Network share support

Postby BrentNewland » 12.05.2010, 17:47

Got the code for elevation (took forever to find)

Here's the elevate.vbs script: http://pastebin.com/A0sKKj60

And here's the code from elevate.cmd (which calls elevate.vbs):

Code: Select all
:: //***************************************************************************
:: // ***** Script Header *****
:: //
:: // File:      Elevate.cmd
:: //
:: // Additional files required:  Elevate.vbs
:: //
:: // Purpose:   To provide a command line method of launching applications that
:: //            prompt for elevation (Run as Administrator) on Windows Vista.
:: //
:: // Usage:     elevate.cmd application <application arguments>
:: //
:: // Version:   1.0.0
:: // Date :     01/02/2007
:: //
:: // History:
:: // 1.0.0   01/02/2007  Created initial version.
:: //
:: // ***** End Header *****
:: //***************************************************************************


@echo off

:: Pass raw command line agruments and first argument to Elevate.vbs
:: through environment variables.
set ELEVATE_CMDLINE=%*
set ELEVATE_APP=%1

start wscript //nologo "elevate.vbs" %*



You should be able to just put the following into update.cmd:
Code: Select all
set ELEVATE_CMDLINE=%*
set ELEVATE_APP=%1
start wscript //nologo "cmd\elevate.vbs" %*


Although I'm not sure how important the environment variables are.
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Re: Network share support

Postby BrentNewland » 12.05.2010, 21:07

That's a good thought, but in order for this code to be accepted into the source, it needs to be usable on all computers. If a network share is read-only, or if someone burns it to a CD, that code wouldn't work.

However, if you have it check whether the folder is writable first, it should work fine.

Here's two methods I found for checking if a folder is writable.

The first:
http://stackoverflow.com/questions/1999 ... ch-scripts
However, it seems to just check for the read-only flag.

The second (and more promising):
http://www.computing.net/answers/dos/is ... 13011.html
The first script listed is more complicated, but is able to catch if the drive exists first and there's media in it (which is important for a CD drive or floppy).
The second script listed is a lot simpler. When I try writing to a dvd via the command prompt, I get an access denied message in the prompt. If I try writing to the DVD drive when there's nothing in it, or to an empty floppy, I get an actual pop-up with Cancel, Retry, Continue. This pop-up can't be avoided with the second method. However, the second method should work just fine for us - since we know where our files are going to be (we have the drive/path stored) our odds of trying to save the log to an empty drive are nil.

Perhaps something like:
Code: Select all
echo testing123 > %~dp0\..\logs\test.log
if exist %~dp0\..\logs\test.log (
set UPDATE_LOGFILE=%~dp0\..\logs\%COMPUTERNAME%.log
del /f /q  %~dp0\..\logs\test.log
)
if not exist %~dp0\..\logs\test.log set UPDATE_LOGFILE=%SystemRoot%\wsusofflineupdate.log










Also, some additional code that the WSUSo might find useful (from old projects of mine):

Code: Select all
; Not sure if WSUSo handles UAC or not for the automatic recall, if not, this code disables UAC. You could put it in the recall files and back up the settings before, when it reboots UAC will be gone
; Disable UAC
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
"EnableLUA"=dword:00000000
;Auto accept UAC prompts, effective immediately
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System]
;"ConsentPromptBehaviorAdmin"=dword:00000002 to reset
"ConsentPromptBehaviorAdmin"=dword:00000000
;Disable black desktop when UAC promps pop up
;security risk: lets other programs mess with the UAC prompt
;[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System]
;"PromptOnSecureDesktop"=dword:00000000


Code: Select all
VBS script to create a system restore point - could be modified to make one automatically. Not sure if WSUS does this already or not.
http://www.winhelponline.com/blog/create-system-restore-point-quickly-using-script-in-windows-7-vista-and-xp/


Batch file to find out if your windows version is x86 or x64 (probably already implemented but may be useful)
Code: Select all
@echo off
if /i NOT "%programfiles(x86)%XXX"=="XXX" (
   if /i "%PROCESSOR_ARCHITECTURE%"=="amd64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITEW6432%"=="amd64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITECTURE%"=="x86-64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITEW6432%"=="x86-64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITECTURE%"=="AMD x86-64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITEW6432%"=="AMD x86-64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITECTURE%"=="Intel64" (
      GOTO 64BIT
   )
   if /i "%PROCESSOR_ARCHITEW6432%"=="Intel64" (
      GOTO 64BIT
   )
) else (
   GOTO 32BIT
)
:64BIT
echo 64-bit Windows installed
GOTO END

:32BIT
echo 32-bit Windows installed
GOTO END

:END
pause
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Re: Network share support

Postby -Iwan- » 12.05.2010, 21:30

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.
-Iwan-
 
Posts: 364
Joined: 02.11.2009, 17:49
Location: NRW, Germany

Re: Network share support

Postby BrentNewland » 12.05.2010, 23:04

-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).
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Re: Network share support

Postby WSUSUpdateAdmin » 13.05.2010, 08:51

Hi Brent,

welcome and thanks for your commitment and your effort. :)
I'll check your your suggestion concerning UNC support, but not before the next week.
Regarding the logging stuff, I think it's a more custom specific thing, so I propose to use the already implemented custom\FinalizationHook.cmd functionality to get the log file copied/renamed/moved.

Thanks & regards
Torsten Wittrock
WSUSUpdateAdmin
Administrator
 
Posts: 2245
Joined: 07.07.2009, 14:38

Re: Network share support

Postby BrentNewland » 13.05.2010, 17:16

It looks like, in update.cmd, just using "DoUpdate.cmd" works when running the update.cmd by itself, but you need to use "start Doupdate.cmd" for it to be compatible with the GUI (because the GUI hides the first window? related to @SW_HIDE).

**EDIT** Found out the problem with that, needed the %* in update.cmd to pass the command line options.

However, I have another issue I just can't figure out.

When I run UpdateInstaller.exe by itself, it flashes up a command prompt window (I removed the hide line) which closes immediately - it's probably erroring out, but I can't figure out how to make AutoIT keep the window open.

When I run update.cmd (and close it before it installs anything), and it makes a network share, then I can run UpdateInstaller.exe (from the UNC path, not the mapped path) and it works fine. I think that the code in UpdateInstaller.exe that detects network drives isn't working 100% (the code that sets $scriptdir).
(if it is that code, either it can be changed so it'll let update.cmd do it's thing, or perhaps we can let UpdateInstaller.exe and start_update.cmd both handle drive mapping - here's info on how to map a drive with AutoIT http://www.autoitscript.com/forum/index ... opic=81302)

I think I've got almost all the bugs worked out, I'm testing it right now on two XP machines. If it goes through good, I'll update the first post with the working changes.




BTW, Why does auto recall create a user account?
BrentNewland
 
Posts: 17
Joined: 15.04.2010, 18:26

Next

Return to Anregungen / Suggestions

Who is online

Users browsing this forum: No registered users and 39 guests