hollisorama

I'm getting the same "HTTP is selected for Client. The current state is 0" when using the Software update Point based isntallation, but it is only happening on clients that are in a remote location accross a WAN over our MPLS network. Clients here at my location, select HTTPS. I'm not sure why. Once the isntallation selects HTTP, it's lights out for the install beecause none of my MPs are enabled for HTTP. Just to check, I changed one MP to HTTP and the installation was successful. Client push installation works just fine and HTTPS and certificates are selected appropriately. I'm not sure why it has this behavior. I'm looking into assigning the client installation properties via Group Policy, but I don't know if the Software Update Based installation will pay attention to those parameters. We'll see.

Changing the SUP to every 8 hours worked like a charm. The SUP kicked off, 1 hour later the deployment deadline hit and so far every system I checked updated their definitions on schedule - including that pesky server in the remote site. (I did take a look at that server and ended up rebooting it earlier today so maybe there was something funky going on with it - I'll continue to monitor it) I think I won't have to change my ADR's to only go back 8 hours either because each time the deployment goes, there should only be one definition update that needs applied no matter what.

OK. Today, all my servers applied all three updates without issue (except one that I'll get to in a minute) I don't understand why it failed the day before. The change in the ADR targeted to my laptop did what I hoped, it only deployed the latest update becasue it only searched back 8 hours. I'm going to change the SUP to sync every 8 hours and see how that goes. I have only one server client in a remote site accross a WAN. It did not update it's definitions last night. It is a distribution point at that site and I checked and it is looking to itself for content source. The distribution status of the EndPoint protection updates was successful so I'm not sure why it did not update it's definitions last night. It would see that it doesn't see that it has a deployment that is needed. It did successfully apply the EndPoint protection updates 3 days ago through the SUP. I'm looking at what the issue might be.

Sorry. After looking at it again, it's not necessarily the latest updates that get installed. I'm changing my Managed Laptop ADR to look back only 8 hours. That should get only the latest update. My laptop is the only device in that collection right now so good for testing. If that works, I plan to change the Software Update Point to sync every 8 hours. I'm on ConfigMgr 2012 SP1 so my ADR's can use the evaluation period "After Software Udpate Point Sync" Then I'll get updates 3x per day which is supported in SP1 - NOT recommended for RTM. I'll let you know how it goes

I've noticed this from the beginning of implementing EndPoint Protection, but usually it is on one or two clients. Today, it showed up on over half (we don't have too many in the heirarcy yet). It's really a false positive because the most recent definitions available in my environment are installed on the client. Why doesn't ConfigMgr just install the latest definition and forget about the older updates? The clients only need the latest one right? I did have one server that successfully installed all three updates so I don't understand what's up. Is there a way to get more information on why the update isntallation fails?

I'm wanting some feedback on deploying the client through the SUP. I have that enabled and a GPO to enable Windows updates on clients. I have tested and the client gets deployed. I'm a little concerned going forward that the automatically approved WSUS updates will get picked up by clients and they will reboot outside of the control of ConfigMgr. This is how I currently have my ConfigMgr Client GPO configured. I've read a little and wonder if these two highlighted policy settings will get my clients installed faster and avoid any reboots caused by WSUS If someone has feedback, that would be appreciated.

This worked for me as the link in the article states You can manually unlock these if the application crashed and you just don’t want to wait. All you have to do is open sql server management studio and run Select * from SEDO_LockState Find the id and place it into the below sql statement and run. delete from SEDO_LockState where id=’PLACE ID FROM ABOVE HERE’

So I'm working through a build and capture and was having the hardest time. I was getting a lot of the same messages on attempting a PXE boot with my VMware ESX 4.1 VM and SCCM 2012 SP1. First, I needed to make sure that I specified a trusted certificate instaed of the self-signed certificate in the distribution point settings (See http://social.technet.microsoft.com/Forums/en-US/configmanagerosd/thread/2e3d5d45-e9e2-4e8f-a306-ab331927e726/) Second, I needed to let SCCM do the install and configuring of WDS on the distribution point. SCCM still put the RemoteInstall folder on the data volume I created instead of the system volume - maybe because of the NO_SMS_ON_DRIVE.SMS on C:\ or maybe it was because on my first go I had tried to install WDS manually. I did follow removal steps for the PXE feature. Basically, I unchecked those options for the distribution point, let SCCM remove WDS, rebooted the server, removed the old RemoteInstall fodler, and then went back and selected the PXE feature for the distribution point. After that, my VM was booting, but becasue I'm on ESX 4.1, it doesn't play correctly with the WinPE 4.0 boot image. I'm still looking at a workaround for that to get a WinPE 3.0 boot image available. Instead, I asked our desktop support group for an old PC I could test with. Once I added it into the correct colelction, it booted great and the task sequence has gone without issue. The image is about 2 clicks away from finishing the capture process. Oh. It's done . In the Build and capture, I even got it to update the Win 7 SP1 image with Software updates and isntalled a couple of programs into the image (Office Communicator 2007 R2, Flash 10 and .NET 4 - all from the Software Model portion of the SCCM SDK) On to deploying. Thanks for this forum. It has been REALLY helpful

For Booting an ESX 4.1 VM, the SP1 boot images won't work because Windows 8 and WinPE 4.0 don't work on that version of VMware. I'm going to see if I can use the boot wim's from my lab site that I haven't upgraded to SP1 yet in my SP1 production

I followed this and it didn't quite work, but I think it was necessary. I had isntalled WDS manually so I could get the RemoteInstall fodler on a particular volume. I wouldn't do that again. The last piece of the puzzle was from this post http://social.technet.microsoft.com/Forums/en-US/configmanagerosd/thread/2e3d5d45-e9e2-4e8f-a306-ab331927e726/ I was running into cert errors because I was still using the self-signed cert on my PXE Distro point. I had already created a cert for the distro points, but hadn't installed it on this one again after I had re-installed the distro point. Thanks for a great forum!

I am trying to customize the Office Communicator 2007 R2 Application that came with the Application Model Kit in the SCCM 2012 SDK. We use Office Communicator, but have it patched. I was trying to work out a way to patch it all in one deployment type, but as I am reading various posts, it sounds like this is not possible. The post above has a good description, but I also had another idea. Could I create a deployment type called "Office Communicator 2007 R2 November 2012 Patch", specify this in the command line "msiexec /p 3.5.6907.266Patch.msp /norestart /qb" and add a dependency for the Office Communicator 2007 R2 deployment type that came from the Application Model Kit? That's what I have right now and I'm jsut beginning to test with it. One thing I wondered about is the Detection Rule that came with the Application Model Kit "Office Communicator 2007 R2" deployment type. I changed that so that it refers to the Product code from the MSI that I have. I'll let you know how it goes