waingro
-
Posts
33 -
Joined
-
Last visited
-
Days Won
1
Posts posted by waingro
-
-
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 do to clear the client's cache of what updates it thinks are available? Thanks!
-
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.
============================================
Version: 2.1.1116.101
Command line: SiteServerName: SCCM; SoftwareUpdateFilter: articleid=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0; PackageName: FEP Updates; UpdateLanguages: 0; SoftwareUpdateFolder: ; DisableRefreshDP: False; LogFile: C:\ProgramData\SoftwareUpdateAutomation.log. UpdateAssignmentName: FEP Updates
Attempting to connect to site server 'SCCM'...
Connected to site server 'SCCM', searching for matching software updates...
Executing select query: 'SELECT * FROM SMS_SoftwareUpdate WHERE articleid=2461484 AND IsSuperseded=0 AND IsEnabled=1 AND IsExpired=0'...
Error: Unexpected exception: The ConfigMgr Provider reported an error.
SoftwareUpdateAutomation execution completed unsuccessfully, errors occurred.
=========================================================
I am using the Update Rollup 1 version of softwareupdateautomation.exe which is why there is no /refreshdp switch.
I tried following this site: http://blogs.technet.com/b/clientsecurity/archive/2011/07/18/errors-when-using-the-fep-2010-definition-update-automation-tool.aspx with no luck. I cannot figure out how to actually run the WMI query to see the listing. I tried wmic and I get an error stating "SELECT - Alias not found." and wbemtest is confusing, to say the least.
Any tips on how to do this or where else to look are greatly appreciated. Thanks!
-
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 snapshots).
Sorry about not checking back - I didn't have any notifications set up. :-/
-
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 all of the patches are constantly available and you'll never have to worry about a missing update.
When the migrated machines get the SCCM client installed they will then be able to scan themselves against your SUP according to your configured scan time and install any updates according to your maintenance windows.
-
Are the missing updates not being advertised to that system somehow?
-
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:
-
It appears you are correct.
-
1
-
-
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.
-
Open the WSUS console and try to connect to the SCCM server. Let me know what happens.
-
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 have one server with multiple MWs, unless, of course, that is your intention.
-
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 servers so the client will use SCCM. We had a second GPO that enabled the "No auto-restart with logged on users for scheduled automatic updates installations". I'm hoping this GPO will have the same effect on the workstations that it did before. I want the updates to deploy and install via SCCM and I want the little nag message to come up for the user so they will know they need to reboot, but they should never be forced to reboot.
Any suggestions? Thanks!
-
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.
-
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 those machines are on VMs except for DPM (DPM is physical since Hyper-V can't pass an attached SCSI device for a tape drive). But, then again, we built the environment with that design in mind, so my setup may not be feasible for your environment.
The point is the System Center suite will run just fine on one or many servers, whether physical or virtual. It all boils down to the physical hardware and storage it is running on.
-
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:.
-
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.
-
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.
-
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.
-
Where are the source files you are using located?
-
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 installs for you during OS deployment. I recommend using a long complex password for the service account.
Basically the account needs to have enough rights to install the client on pre-existing machines (IF you aren't refreshing the OS using SCCM) and it needs local admin rights on the SCCM server and the remote SQL server (if applicable).
-
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 it somewhere accessible to the task sequence.
regedit /s regfile.reg
-
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.
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.
-
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.
-
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 properties.
Possible cause: The SMS Service might not have access to some properties of this object. The container specified might not have the properties available.
Solution: Please verify the Active Directory schema for properties that are not replicated or locked. Refer to the discovery logs for more information.
This is an error I commonly get. I believe it is due to these accounts being obsolete and have not been removed from AD yet.
Also this thread, http://social.technet.microsoft.com/forums/en-US/configmgrgeneral/thread/767da4d4-3054-45ff-8829-f5dbb1d1e778/, seems to point to DNS not having active records for those machines, which could also be a result of an inactive account.
-
1
-
-
I typically see this when SCCM is scanning AD and finding machine accounts that are no longer active in AD.
SCCM No Longer Downloading Updates for FEP 2010
in Endpoint Protection
Posted
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 is pulling that version from WSUS/SCCM instead of MS Updates.
So it appears to me that the problem is within WSUS, so how do I get it to pull the new definition updates? Thank you all.
ConfigMgr 2007 SP2 R3, FEP 2010 Update Rollup 1, Server 2008 R2 w/ SP1