Jump to content


waingro

Established Members
  • Content Count

    33
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by waingro

  1. Hello all. I have recently realized that my SCCM server is no longer downloading the definition updates for FEP 2010. I have an update from May 31 (definition version 1.127.1100.0) - it shows as not expired and not superseded in SCCM. It is also the latest version showing in the WSUS console. When I manually run the softwareupdateautomation.exe tool I get this: Adding update CI_ID: 89097. ArticleID: 2461484. Name: Definition Update for Microsoft Endpoint Protection - KB2461484 (Definition 1.127.1100.0) to successfully processed list. That definition version is way old. I'm assuming it
  2. So I was trying to get the Adobe updates working through SCUP and SCCM and the package got published accidentally to the updates collection. Before I knew what I had done one of the client machines saw the updates and notified the user that they were available. I was simultaneously trying to remove those updates from that collection and in doing so I caused the updates on the client to fail. The computer has completed several software update scans since, but still shows those updates and fails trying to install them. I have re-pointed the package back at that collection to no avail. What can I
  3. About a month ago or so our automation tools for FEP definition updates stopped processing those updates. It had been working fine for almost a year. When I run the FEPUpdates.cmd (contains this command): "C:\Program Files (x86)\Microsoft Configuration Manager\AdminUI\bin\SoftwareUpdateAutomation.exe" /AssignmentName "FEP Updates" /PackageName "FEP Updates" /UpdateFilter "articleid=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0" I get this error in the %Programdata%\SoftwareUpdateAutomation.log file: SoftwareUpdateAutomation execution starting. =================
  4. Sounds/looks like you are trying to edit a vhd that has multiple snapshots associated with it, which is likely causing your issue. With your software based snapshots you may want to contact the vendor for tech support to merge those files. For more understanding: http://www.networkfo...shots-back-one- If you look in the VM folder for the vhd and you see files with the extension of avhd that means that a snapshot or snapshots have been taken. Every time a new snapshot is made a new avhd file is created and all changes to the VM are written to that file (this is specific to Hyper-V snapsho
  5. If you have deployed all the available/desired patches and have them advertised to a collection then the machines will scan themselves against your SUP and install any missing updates upon being assimilated into your SCCM environment. You can then use reporting, assuming you have setup an update list or lists, to view their compliance levels. I have a separate package for each year's updates, except for 2003 - 2005 which are small enough to fit into one package. I leave them advertised to my update collection 24-7 and only mess with them when an update gets superceeded or expires. This way
  6. Are the missing updates not being advertised to that system somehow?
  7. This is what I've done for Server 2003 VMs - shut down the VM, edit and expand the hard drive, start the VM and use disk manager to expand the C: drive. If it was set as fixed when it was originally made then that may explain why you don't have the option. If that is the case then see here: http://social.techne...3-a900054e93a1/ You should see a couple good articles linked that in one way or another help you in your dilemma. A walk-through for expanding VHDs: http://www.petri.co....ith-hyper-v.htm
  8. Based upon the location of the inf file I don't think it is a driver loaded into SCCM, but instead it is likely a driver in the OS source. Instead of C:\_SMSTaskSequence\drivers\ it is X:\WINDOWS\INF\, and X: is the mount point for the OS image you are using.
  9. Open the WSUS console and try to connect to the SCCM server. Let me know what happens.
  10. The server that is in both collections would obey the maintenance window you have set on one collection and install updates based on it even though you've deployed the updates/software to the collection without the MW. The server/client doesn't care what collection it is in. It only knows that it has an advertisement and a MW. Think of it as cumulative information. If you want to deploy software updates to a parent collection then you should split your collections up by maintenance windows and put only the servers you want to obey that MW in that collection. Don't double up or you'll
  11. Hi everyone, I am curious what you think the best practices are for deploying updates to workstations but keeping them from automatically rebooting. We have certain workstations that are used 24-7 so we don't need them rebooting in the middle of someone's work, but I need to ensure updates are deployed. We currently have these machines broken out into a separate OU with a no forced reboot group policy applied. My question is will that GPO play nice with the maintenance windows in the SCCM collection? Some details - we were using WSUS. I've since removed the GPOs pointing to the old WSUS se
  12. Have you double checked your TS under the install ConfigMgr client to verify it is still correct? Tinker around with it. If you can't get it to work then a build and capture TS to create an image may be your best bet as Eswar has pointed out.
  13. It really depends on your environment and your budgetary limitations, with the biggest issue you need to worry about being licensing and hardware. If you have a solid virtual environment, licensing availability, and space for separate VMs, that's the way I would go. Otherwise, if OS licensing is limited I would use on beefy box and run all the systems on it. I'm a fan of separate VMs for all my System Center servers. We have a four node cluster running server 2008 core which provides us with HA VMs. I have SQL on its own VM and it is the backend DB for SCCM, SCOM, SCVMM, and SCDPM. All of
  14. When you create the OS System Image it will always go to D:. Create an OS Install Package from your source files and specify "Apply operating system from an original installation source" under the task sequence>>Apply Operating System step. Point to the OS install package under that step and your OS will now be installed on C:.
  15. Under the program properties click Browse and point to the executable that way - then append your command line switches. That will ensure you don't have a typo causing an issue. HTH.
  16. Your cache size may be too small for the program - how large is the content? This is one reason I prefer to install programs from the distribution point. I get a much faster installation time (starts immediately as opposed to having to wait to download files) and less bandwidth saturation.
  17. As far as drivers that don't "play nice" I have resolved myself to use images for them. HP's fingerprint scanner, quick launch buttons, and hard drive fall sensor drivers don't play nice and it's far less painful to just use an image for those machines.
  18. We already had a group that granted local workstation admin rights to our deskside team which was enforced using a GPO. We put our SCCM service account in that group so we could deploy clients to a pre-existing environment after enabling certificates for native mode. Don't use this approach on a DC! That'll give the service account domain admin rights - just do a manual install on those machines. Once the client has been deployed across the domain you can remove this membership as long as you are deploying OS's using SCCM - the services run as Local System and SCCM will handle the new client i
  19. Group policy is the best way to handle this. For Server 2003 - http://technet.microsoft.com/en-us/cc835026 For Server 2008 - Group Policy Management Console - GPO for this setting - Computer Configuration>>Policies>>Administrative Templates>>System>>Logon>>Assign a default domain for logon. If that's not an option you can use the command prompt in a TS to merge a registry file at this location: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName The easy way to set it is to modify this entry on a computer, export it and save
  20. One way to avoid it is using the build and capture sequence - handy if you have laptops that don't have drivers that play nice with SCCM. http://social.technet.microsoft.com/Forums/en/configmgrosd/thread/0fe09fdc-fab6-4dc5-811a-ee93557f89a7 I copied the contents of the Windows 7 DVD to a network location and made an installation package from it using the 'Add Operating System Install Package' wizard. From there edit the task sequence to specify that installation package and specify that it should be placed on drive C:. That has worked wonderfully for me.
  21. How often is your SCCM server scanning AD? You can tinker with those settings to deploy software a little more quickly. One of the gripes I have about SCCM is the inability to easily push software immediately to a system.
  22. Verify the computer account in AD is, in deed, obsolete and delete it from AD. SCCM should pick up the change and remove it from its DB on the next scan. There is also a rights issue, meaning the account (hopefully a service account) that SCCM is using to scan AD needs to be able to read the AD attributes. That could be your issue as well. SMS Active Directory System Discovery Agent reported errors for "X" objects. DDR's were generated for 0 objects that had errors while reading non-critical properties. DDR's were not generated for "X" objects that had errors while reading critical pro
  23. I typically see this when SCCM is scanning AD and finding machine accounts that are no longer active in AD.
×
×
  • Create New...