Reusing Downloaded Updates Stored on SQL "John T" <johnt[ at ]nomail.com> 5/22/2007 6:31:09 PM If wsus v3 is configured to use a seperate SQL server to store updates, could the server running wsus be rebuilt on another box and be pointed to the sql database containing the updates without having to redownload them all again? I realize you would have to re-approve the updates and recreate the groups but aside from that could the existing updates be pointed to from another wsus install and work? Thanks

Re: Reusing Downloaded Updates Stored on SQL "Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/22/2007 10:38:01 PM "John T" <johnt[ at ]nomail.com> wrote in message news:eMfyl%23JnHHA.960[ at ]TK2MSFTNGP03.phx.gbl... [Quoted Text] > If wsus v3 is configured to use a seperate SQL server to store updates, > could the server running wsus be rebuilt on another box and be pointed to > the sql database containing the updates without having to redownload them > all again? Yes. > I realize you would have to re-approve the updates Not really.. I'll explain shortly. > and recreate the groups Nor this... > but aside from that could the existing updates be pointed to from another > wsus install and work? Yes. The =database= contains all metadata about the updates, including which ones are approved, as well as all information from client reporting. Pointing a (new) front end server to an existing back-end database is as easy as installing the new front-end server just as if it were the original front-end server using the instructions in Appendix C of the WSUS Deployment Guide. Unless you destroy the database, you will not have to reapprove updates, nor recreate groups. The update content is stored in the filesystem on the front-end server. You'll want to XCOPY that from the old front-end server to the new front-end server /before/ installing the WSUS software on the new front-end server, otherwise, the new front-end server will try to download the content. -- Lawrence Garvin, M.S., MCTS, MCP Independent WSUS Evangelist MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx And, almost everything else is at http://wsusinfo.onsitechsolutions.com .....

Re: Reusing Downloaded Updates Stored on SQL "John T" <johnt[ at ]nomail.com> 5/23/2007 12:33:11 PM Thanks Lawrence, Looks like I was a little backwards on the configuration settings then. I was thinking the downloaded contents (actual update files) were stored in the database and the metadata was located locally. If XCOPY would work for moving the data from one server to another, does the data need to reside on the same drive letter? Is it possible to use a LUN on a SAN for the data and simply assign a different physical host to the mapped LUN using the same drive letter? Would this work as well, aside from losing the permissions? Im not sure if the permissions and security rights assigned to the data are specific and granular so this question may be moot. Thanks "Lawrence Garvin (MVP)" <onsitech[ at ]community.nospam> wrote in message news:e3pobHMnHHA.4196[ at ]TK2MSFTNGP06.phx.gbl... [Quoted Text] > "John T" <johnt[ at ]nomail.com> wrote in message > news:eMfyl%23JnHHA.960[ at ]TK2MSFTNGP03.phx.gbl... >> If wsus v3 is configured to use a seperate SQL server to store updates, >> could the server running wsus be rebuilt on another box and be pointed to >> the sql database containing the updates without having to redownload them >> all again? > > Yes. > >> I realize you would have to re-approve the updates > > Not really.. I'll explain shortly. > >> and recreate the groups > > Nor this... > >> but aside from that could the existing updates be pointed to from another >> wsus install and work? > > Yes. > > The =database= contains all metadata about the updates, including which > ones are approved, as well as all information from client reporting. > Pointing a (new) front end server to an existing back-end database is as > easy as installing the new front-end server just as if it were the > original front-end server using the instructions in Appendix C of the WSUS > Deployment Guide. > > Unless you destroy the database, you will not have to reapprove updates, > nor recreate groups. > > The update content is stored in the filesystem on the front-end server. > You'll want to XCOPY that from the old front-end server to the new > front-end server /before/ installing the WSUS software on the new > front-end server, otherwise, the new front-end server will try to download > the content. > > -- > Lawrence Garvin, M.S., MCTS, MCP > Independent WSUS Evangelist > MVP-Software Distribution (2005-2007) > https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E > > Everything you need for WSUS is at > http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx > > And, almost everything else is at > http://wsusinfo.onsitechsolutions.com > .... > >

Re: Reusing Downloaded Updates Stored on SQL "Lawrence Garvin \(MVP\)" <onsitech[ at ]community.nospam> 5/28/2007 4:41:17 AM "John T" <johnt[ at ]nomail.com> wrote in message news:ec2yPbTnHHA.4628[ at ]TK2MSFTNGP06.phx.gbl... [Quoted Text] > If XCOPY would work for moving the data from one server to another, does > the data need to reside on the same drive letter? No. There is a feature in the wsusutil.exe utility that can be used to move a content folder to a new location, or simply tell an existing WSUS server that the content folder has been moved to a new location. However, on a *new* server, simply create the content store (during installation) at the pathname you intend to XCOPY the actual store into, or give WSUS the name of your existing content store (if you XCOPYed it before installation). > Is it possible to use a LUN on a SAN for the data and simply assign a > different physical host to the mapped LUN using the same drive letter? In WSUS 2.0, no. However, WSUS 3.0 may be a bit more forgiving. Technically WSUS 3.0 doesn't support network attached storage for the content store, but the "network load balancing" configuration does document how to use DFS to direct multiple WSUS front ends to a single DFS resource. I then posited the hypothesis that one could do this for a single front-end server -- if it works for two (or more), it certainly should work for only one. Nobody has discounted my hypothesis, yet, except to comment that it wasn't part of the intended product design scenario. > Would this work as well, aside from losing the permissions? Im not sure if > the permissions and security rights assigned to the data are specific and > granular so this question may be moot. I'm not exactly sure how WSUS 3 handles the permissions issues. In WSUS 2, the issue revolved around BITS running in the context of the local machine's Network Service account, which cannot be granted write permissions to a network resource. I've not looked into the internals of this process, yet, to determine the differences, though I suspect it has something to do with using the DFS interface. -- Lawrence Garvin, M.S., MCTS, MCP Independent WSUS Evangelist MVP-Software Distribution (2005-2007) https://mvp.support.microsoft.com/profile=30E00990-8F1D-4774-BD62-D095EB07B36E Everything you need for WSUS is at http://technet2.microsoft.com/windowsserver/en/technologies/featured/wsus/default.mspx And, almost everything else is at http://wsusinfo.onsitechsolutions.com .....