Iroqouiz

Thanks a lot. Will try.

Have you specified your MP in the Config Mgr client installation properties?

Hey, try this http://blog.coretech...n-manager-2012/ This will send an email to the person listed as the user's Manager in AD. Coretech are developing a new version which will let you set a static email address instead, like your IT department. Don't know when it will be ready.

Yes you can. Check this http://www.nirsoft.net/utils/iconsext.html

Don't use IP subnets, use IP address ranges instead. http://blog.configmgrftw.com/?p=343

Have this exact problem. Asked around here and on Technet for advice but never got a reply. My workaround is the following: 1. Create one UDI.xml file for each OSD task sequence I want where I specify which image should be applied (this is just cosmetic, so that my colleagues can verify which image they've chosen. Like you said, the actual image being applied is hardcoded in the TS). 2. In my "MDT package folder\scripts" I've created subfolders for each UDI.xml, naming them after which OS image it's going to install. In the subfolders I've also copied in UDIWizard.wsf and ZTIUtility.vbs. You need to edit UDIWizard.wsf in each subfolder so it can find your UDI.xml file (if you've renamed it, if it's standard it should be ok). 3. Create one TS for each UDI.xml file and set the correct OS image. In the step where the TS calls UDIWizard.wsf you need to make sure the path is correct, i.e. point it to your subfolder for that particular script. No doubt this could be done easier than I've done, but this works great for me. Can't for the life of me understand why dynamic image selection with UDI doesn't work from the beginning though.

Sure you can have it on the server. We just don't manage servers in our environment, only workstations. And when I'd accidentally installed the client on the site server, and then only half-removed it, it messed things up for me. So I needed to make sure it was completely gone, hence using the good old ccmclean from SMS Toolkit 2003.

I think those updates should be removed automatically when the SUP does its scheduled sync. That has never worked for me, however.

Check the permissions on the share where your WIM is going to be placed.

Yeah, this is what I'm about to try. Thanks.

Hi, Like I wrote: add SMSMP=server.domain.com (replace with your own SCCM server's FQDN)

bob88: you have some errors in both the smsts and appenforce log files. In your "Setup Windows and Configuration Manager" step, have you specified any installation properties? In the smsts log file, I saw some errors about MP (management point). Try adding SMSMP=sccmserver.domain.com to the installation properties in the step mentioned above.

Hey, that log file is in c:\windows\ccm\logs. It will only be there if an application installation has actually started, though. Check appdiscovery.log for information. Both of you: have you checked this box on your applications? It's needed for installing apps in a OSD task sequence.

Perhaps you can add the Java 32 bit to the task sequence, but create a condition on it so that it will only install if it already detects you have Java 64 bit?

Yes there is. Create a new package from definition.

I have no idea why people think SCCM is better that WSUS to deploy updates with. WSUS is so easy, SCCM is too complicated.

Could this not have something to do with that SCCM only stores a driver once on the DP? If you import drivers for three computer models that are in the same series, they often have the same drivers. I don't think SCCM imports the driver three times, it only does it once. Maybe this is why the folder size is different. Not sure though, could be way off.

Hey, please copy and paste the info from zticoalesce.log, smsts.log, appdiscovery.log, appenforce.log (probably forgot some logs but those are good to start with). These logs should be in c:\windows\ccm\logs on the client machine.

There's a whole bunch of driver related error messages in that log file. Have you added NIC/HDD drivers to your boot image?

Thanks for the tip. I will try to test that, if management will allow me. I just think it's weird that the Windows 7 Updates work. If the problem was with WSUS GPOs, wouldn't those update also fail?

x I chose your way, kind of. I set up my new SCCM 2012 server and made sure that OSD worked like it should, which is the most important thing for us. Our environment isn't big at all (300 users, maybe 450-500 machines, not that many applications/packages). So I started recreating all our old 2007 packages in 2012, fiddled around with the app model, tried different stuff just to learn. I followed the guides on this forum to set things up. x You have to set up boundaries (use IP address ranges) and boundary groups so clients know where to look for content. Just make sure that you don't enable the boundary group for site assignment! That can really mess things up in your current environment. You can trigger all the discovery methods appropriate for your site, but as long as automatic site assignment and automatic client push is not enabled, nothing will happen to your old 2007 clients, don't worry. x I can't begin to tell you how many gotchas I've encountered. It's good that you have a year to set up the new environment. I did it in 5-6 months, and that was enough time for me, as an inexperienced SCCM admin. One gotcha that I can think of now is PXE boot. Make sure that you tick "Deploy this boot image from the PXE service point" on the Data Source tab of your Boot Image properties. Also, let SCCM install WDS for you. Regardless of what any SCCM MVP says, and there are many who think this, PXE can be a bitch to get working if you manually install WDS. I did it two times, and never got PXE to work. A couple of weeks ago I uninstalled WDS and let SCCM install it for me, *boom* started working immediately. Software Updates are another thing that's giving me a terrible headache right now. Haven't figured it out, but be prepared to scratch your head. x Those sites are basically the ones I look at. Google will be your best friend. You should really learn how to read the log files on the server and clients. This will give you error codes which you can then google. x Didn't use anything other than a simple Word document. But I'm not good at planning projects, I just do stuff. I should probably learn. x Don't have any good links for, I'm afraid. My recommendation is that you start building both packages and applications in your SCCM 2012 lab. Just test stuff. This is the only way you will really learn. Set up a lab with virtual machines that you can re-image over and over again. Test the apps/packages on those VMs. When I was happy with my 2012 server (or as happy as I could be, still having issues with some stuff) and felt I had learned to manage it, I started migrating some stuff from the old server. I only chose some packages, stuff that I hadn't felt like building on my own. I didn't need to migrate anything else since I had taken the time to learn and set up my collections, queries etc by myself. After you've migrated whatever packages/collections you want, check the Client Push properties. Add SMSSITECODE=sitecode and SMSMP=server.domain.com. Start to actually migrate the clients. Just do a couple at a time. Wait until the next day and check the clients tab in the Monitoring node in the SCCM 2012 console. Make sure that they're healthy. Wait a bit more just to confirm no user are experiencing any issues. Then you can start to migrate all the remaining clients. Create a collection with a query for all clients without the SCCM 2012 agent, and one with a query for those who have the agent. This will let you see exactly which clients are not letting you push the agent to. Many MVPs think Client Push is a bad idea. For me, 15 clients out of 450-500 machines would not install the new agent. For those I have to install the client manually or use a log on script, GPO or whatever. Maybe Client Push is not for you.

Thanks for taking the time. Sorry, should have been more clear. Office 2010 is in the image, installed during my B&C. The install applications step in the deploy TS is just other stuff, Java, Flash and so on.

Hi, I'm having issues with Windows Updates for Office 2010 during OSD. My normal deploy TS are just not installing them. Windows 7 Updates install just fine. All machines are recognized as "bare metal" by my server, even in refresh scenarios. So my TS is deployed to the All Unknown Computers collection. I've deployed my two Software Update Groups (Windows 7 and Office 2010) to the All Unknown Computers collection. This made the TS fail (smsts log says Timedout waiting for updates refresh complete notification). If I remove the Office 2010 Updates deployment the Windows 7 Updates are being installed in the TS. I have tried creating more Install Software Updates steps in my TS, with scans and reboots in between, but nothing works. I have tried calling scripts that are supposed to trigger WU to allow installation of updates other than Windows 7. No luck. My TS looks like this, some steps are disabled by me for testing purposes I can't believe how difficult Software Updates are to manage in SCCM 2012. We have a WSUS server separate from my WSUS installation on the SCCM server, but this shouldn't mess things up during a TS, right?

Try this http://myitforum.com/myitforumwp/2012/10/09/kb2509007-strikes-configmgr-2012/?utm_source=dlvr.it&utm_medium=twitter&utm_campaign=kb2509007-strikes-configmgr-2012

Hi all, I've deployed a bunch of apps for users to install via the App Catalog. I also want them to be able to uninstall the application via Software Center. This all works fine. However, soon after I uninstall the application, a notification pops up that says the application is Past due - will be updated. I don't understand why. The application deployment is set to Available (otherwise it couldn't be installed from the App Catalog), so why does the SC think it needs to be re-installed?