Gorilla

Good point. I forget about stand alone WSUS after spending so much time with SUP. I'll use that jargon in the future.

Thanks a ton Peter. It appeared that was how it functioned. I will make sure to use the "ignore maintenance window" option for any deployments that are offered insted of mandatory, as the application deployment management strategy I'm using only really has Offered and Mandatory advertisements. And I assume this effects WSUS updates too (Maint. Windows) but those only get pushed out in the night and it would be an improvement to prevent missed ones from running during business hours. I had been "dialing-in" slowly and measuring impact. Seems judicially used and properly configured MW's aren't an option. Thanks again!

I am trying to perfect my managed application strategy. Using this scenario, please advise. Collection A has 50 computers in it and no maintenance windows. Advertisement 1 is created, targets Collection A, and is mandatory so WoL can be used to turn on the computers during off-hours. 1 month later, Computer 51 must receive this required application after hours using WoL and is added to Collection A. Question: In this situation, is the 1 month old mandatory assignment seen as passed and Computer 51 will begin installing as soon as it recieves the job and package? Or does the mandatory assignment only apply to computers in the collection at the time it triggers and then just stay dormant? I could address this many ways depending on the behavior. Assuming it doesn't just trigger and die and applies to computers added to the collection later , the options I see are: 1) Add Maintenance Windows to managed application collections to allow them to run only after hours, or; 2) Manually delete the mandatory assignment (not the advertisement) after it runs and then add a new one whenever a new client is added and set re-run behavior to re-run only if failed to prevent it from running again on the current computers. Can anyone validate this strategy and my comprehension of how this will function. Am I missing any attractive options? My preference would be to use #1 since it's a 'set-it and forget-it' solution and I'm ambitiously lazy. #2 is just for kicks and to make sure I understand the nuances of managing mandatory assignments and reducing impact to production systems during production hours. I could test this myself, but IT is already a 'spend-a-lot-of-time focusing alone' job. Sometimes I like to hop on here and get opinions if I cant find an answer. And as I couldn't find one, hopefully it will benefit posterity too. Thanks everyone!

I have an application that points at a license server. The server name is in a HKLM/Software/<name>\License\<dword value> registry key. I need to update the value. I've done lot's of login scripts that import registry settings and wanted to use SCCM to hopefully have a tested way I can execute a Reg command on clients to get away from the login script model. These are all 32-bit XP clients. So basically I have a DWORD value of <servername> in a .reg file with the command regedit /s <file>.reg (and I've tried Reg /import as suggested) My problem it turns out is executing the command while having having the reg file on a network share. I have both tried using a UNC and a mapped drive letter and it fails. If I place the file on a local drive, it works. I had hoped that SCCM abstracted that when I built a package but I'm guessing that's my problem. So unless I learn otherwise, I'll just put the logic in a script (copy file locally > execute file > check value > delete file) and at that point, I don't even need SCCM. Though if it's possible, I'd like to understand the best practice methodology. I've never run out of situations where a registry value needs to be added, deleted, or modified on a host of clients.

Thanks for the response. You are absolutely right that I both forget how good the help is in SCCM (not used to that!) and that I didn't use it. I needed an excuse to visit your site again anwyay. :>) If it's any consolation, the help didn't help me in this case though. Just got back to checking the status of my task. It reported as succeeded but then when I checked, the registry value was not updated. Which is strange because it did work in my test with one machine. All I changed was the collection. No I do not have the file locally and I hope that I won't have to as that would be hard to do on all clients for advertised tasks. Instead I created a package on a network share that is accessible by the install base. And it did work when I tested it, so now I'm thinking maybe they are one hit wonders and I needed to re-advertise it when I changed the collection and schedule. I'll need to mull this over tomorrow so if you see any obvious misconceptions on my part, I'll appreciate having them pointed out. Cheers! -Kelly

I'm using a task sequence to only run a command. For example: regedit /s <file>.reg I'm setting one up for the first time and I created the task, edited it, added the Run Command Line task, and then placed the above in the command line field. Then I placed the .reg file on a network share and placed that path in the Start In: field. Finally I advertised it to a collection with one workstation for as soon as possible and made it mandatory with WoL. It didn't work until I abandoned the "Start In" field and created a package out of the reg file. So what is the purpose of the 'Start In' field if it isn't the working directory? I didn't change the location of the file, only made a package out of it and cleared the 'Start In' field. So while I've figured out a way to do it, every reference I've found to the 'Start In' field in task sequences touts it as the working directory. Looking for any clarity in how Task Sequences used for Command Line tasks should be leveraged, especially if there's a file involved. Thanks a ton!

Okay my trials and tribulations shall shine for posterity. It worked! First time so wasn't sure what to look for. Here's what a successful statelog.sys summarization looks like (append to above): SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:01:057: summarizing status for CI 58630 SMS_STATE_SYSTEM SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:01:057: summarizing status for CI 58632 SMS_STATE_SYSTEM SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:01:073: summarizing status for CI 58641 SMS_STATE_SYSTEM SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:01:073: summarizing status for CI 58648 SMS_STATE_SYSTEM SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:01:073: summarizing status for CI 58657 SMS_STATE_SYSTEM SQL MESSAGE: spTask_SUM_UpdateStatusSummarizer - 11:05:26:730: spTask_SUM_UpdateStatusSummarizer done SMS_STATE_SYSTEM Task 'SUM Update Status Summarizer' completed successfully after running for 735 seconds, with status 20703. SMS_STATE_SYSTEM It took 13.5 minutes to complete. Upon Refreshing VIOLA! I'm going to chug some coffee and do a jig. Oh then I'm going to secure my clients. :>)

Bah no joy. Statesys.log reported: Found new state messages to process, starting processing thread SMS_STATE_SYSTEM 8/11/2010 11:00:30 AM 7916 (0x1EEC) Thread "State Message Processing Thread #0" id:6668 started SMS_STATE_SYSTEM 8/11/2010 11:00:30 AM 6668 (0x1A0C) Thread "State Message Processing Thread #0" id:6668 terminated normally SMS_STATE_SYSTEM 8/11/2010 11:00:30 AM 6668 (0x1A0C) CThreadMgr::ThreadTerminating - All threads have stopped running SMS_STATE_SYSTEM 8/11/2010 11:00:30 AM 6668 (0x1A0C) I then refreshed the home page sumamrization and all updates since MS10-46 show as Unknown still. I'm relying on this article a bit: http://technet.microsoft.com/en-us/library/bb632932.aspx Any report that relies on Update Lists can't help me since I use the Search Folder, which seems predicated on the Home Page summarization, to decide what to add to the update list. So if I can't rely on reports that need accurate update lists, and I can't tickle the Summary page to be accurate, I am at a loss for a graceful method. For now I'm going to create an ad hoc update list out of the new updates purely to run a report and see what I need to approve. This is a lot more work then I use to do with WSUS alone, and while I see a lot of long term benefit to the SCCM-way, this kind of funkiness is disarming. So I'm open to ideas.

Hold steady...I just found the Home Page Summarization feature. Waiting for statesys.log to report it's complete, then hopefully a refresh and an updated to my process is all that's needed! Will report back, hopefully soon. How long can this take? LOL

I rely (should I - is there a better way?) on the Search Folders' Installed / Required / Not Required columns to add updates to my monthly security Update List. I am failing to comprehend when and how it is updated. I just took one client, did a Software Update scan, watched it finish in the logs, then ran the Compliance 6 - Specific Computer report and saw that it requires some of the new updates. I did the same for my SCCM server. Same results. However when I am in the Search Folder and want to add only the updates required by a client to the appropriate update list, all the new ones are listed under the Unknown column. So I ran a client Software Scan sync on one client and one server. Checked the logs to ensure it finished. Ran the Compliance 6 report and saw that some of these new updates are seen as required. So here are my questions: 1) How do I get the Search Folder pane to update the compliance columns? What triggers that normally? 2) Is there a silver bullet for figuring out which new updates to add to your update lists if these columns aren't populated? 3) Is there a way to remotely trigger an entire collection to scan for software compliance? I can do it per DDR using Client Center right click functionality, but the update scan isn't available on a collection. Based on the reports I'm running, it does seem that I can find out in a very convoluted round-about way which updates are required by my different architecture's. I find the search folder columns invaluable in making decisions on which updates to add to which update lists each month. And I would have thought they look at the same table and data that the reports are looking at, but apparently I'm still missing some of the magic. Since the reports know, I believe my compliance scans are happening. So my guess is this is just about Question #1 and the other two can be ignored if that's the case and there's a way for me to update those with the data the DB obviously has. I'm reluctant to add the Required value to my search folders until I see and understand when that will manifest in conjunction with syncs and scans. I created one to test and even though SCCM scanned and knows it needs some updates, it doesn't list these as required in the Search Folder. Thanks for any and all assistance. -Kelly

Assuming settings are part of configuring SUP, I'll post this question here. When updates are configured to not require a client to reboot (For example: emergency dispatch systems) automatically, I get the package and red arrow in the system tray. Is there a way to force visible reminders to reboot? I'd like something flashier and more pesky than the little box and arrow. I've been through all the settings and all I find is reminders that a reboot is going to happen, but when one is needed and not forced, can SCCM be configured to pester systems that are always on until they reboot? Much thanks for any and all ideas. -Kelly

YES! The obviously named ScanAgent.log is perfect. Unrelated to scanning, I also use the WUAHandler.log as it let's me know the status of updates being installed and such. I also verified a scan does happen after a deployment. I am very interested in caching behavior and the Technet article handled that as well. I suspected and am happy to learn that it does verify an update is still needed before downloading files to the cache. Does it only pre-cache for mandatory deployments? I have server admins who need to manually install updates and I'd like to alleviate them of having to wait for the download. Any methods for making an update available but not mandatory and having the files in the client cache ahead of time? Thanks Niall. This saved me some digging time. I've added this information to my knowledgebase.

Please correct any misunderstandings here: Software Update Compliance Scanning is via the Software Updates Client Agent and can be evoked manually or automatically. Manual scans can be called from the client or remotely. Automatic scans, when they occur, and how you can monitor their progress are what I'd like to capture in this thread. Your automatic scanning interval is set in the Software Updates Client Agent Properties on the General tab. I *believe* scans also happen immediately after a scheduled deployment finishes. Can someone corroborate whether a compliance scan occurs in relation to a deployment, and at what point please? I rely on the Scan 1 - Last Scan States By Collection report. When it indicates a scan is currently running, is there a log file or method I could use on the client that is running a scan to monitor its progress? I want to figure out what's occurring during a scan and how long it takes a particular client to conduct one. Is there a better way to monitor scan states? My understanding is that scanning is done by the client but triggered or scheduled and involves reporting back to SUP via IIS. So scanning issues might only be a reporting issue which could be IIS and not indicative of a client failing to scan. Is there a file in the outbox (?) or somewhere on the client that one could verify a clients' scan results if reporting is suspect? Do I have anything wrong there and can anyone build on this? Thanks!

There is no switch between the test server and client. Same subnet. And yes the port change worked. So somehow, Port 9 is broken on the server side. Strange days indeed. My spidey senses told me to try a port change hours ago, but my common sense told me that didn't make any sense. But as any good troubleshooter must do, I went back to basics and walked the tree. Alas the senseless prevails! Mr. Spock would never have cut it in this industry.