nry

OK, changing the domain admin password within the discover methods was the key, we altered the admin password on the domain and didn't update SCCM!

Our Device Collection groups are based on OU location - as such, SCCM then picks up devices automatically in the right Device Collection as they are discovered. For some reason, on computers where the OS has been deployed through MDT/SCCM via PXE boot, the 'System OU Name' discovery variable is not being collected. These computers therefore have to be manually assigned to the appropriate device collection. Our discovery processes run regularly and have been manually run, but these settings are still not appearing in the properties of devices within SCCM. If we look at devices which had the OS pre-installed, this variable is collected correctly. We are using Win 7 Enterprise x64 SP1 exclusively across all devices. Thoughts welcome, it would be nice to get this one little thing sorted out

I've got SMSCACHESIZE set in all the places I can, within the push settings and within the task sequence that deploys Win7...none affect deployed PC's, only those PC's where we manually installed Win7, joined the domain, then SCCM picks them up and deploys the client automatically - these ones pick up the SMSCACHESIZE variable.

Is there any way we can have newly built computers set with a custom maintenance window so that they pick up all deployed software without having to wait for the next available Maintenance Window set on that collection? As a school it is preferrable to have these computers fully available as soon as possible if they've been built - currently, if we deploy an OS then move the PC in SCCM to a suitable Device Collection (e.g. ICT Suite), it never picks up any deployed software until the maintenance window is available (set outside of school hours). I'd much prefer any deployed software to go straight onto a deployed OS (Task Sequence during build is not entirely appropriate nor manageable due to the level of new software titles we get) without this delay - is there any way this can be done?

OK, startup doesn't seem to work, however running on Shutdown does - for new OS deployments there are enough shutdowns during the install that it gets picked up before the login screen is finally available. We run this at shutdown (not ideal as it runs at ever shutdown but it works for now): On Error Resume Next Dim nValueToSet Dim oUIResource Set oUIResource = CreateObject("UIResource.UIResourceMgr") Set CacheSize = oUIResource.GetCacheInfo newCacheSize = 25000 if CacheSize.TotalSize <= newCacheSize then CacheSize.TotalSize = newCacheSize end if

Still doesn't work, the cache size remains default. I've just tested a computer startup script to set the cachesize - so far so good. This link discusses the reason why SMSCACHESIZE during OS deployment is not used: http://myitforum.com/myitforumwp/2012/10/04/confirmed-smscachesize-is-ignored-in-configmgr-2012/

Just trying creation of a new Package and not using a definition - added the same package source as the definition uses for the client and added the command lines you mention, obviously altering them to suit our setup. Time will tell

I'm also curious how you set those parameters you mention? CCMSETUP.EXE /mp:SERVER SMSSITECODE=XXX /noservice FSP=SERVER SMSCACHESIZE=20000 You can't set these when you create a package from a definition unless I'm missing something?

I am most definitely using a new client package following the instructions from this site and I have that parameter set - whilst it works deplying the client to a pre-installed computer, if you use MDT to deploy the OS via SCCM 2012, that parameter is ignored and this fact is documented by MS. I cannot get this parameter to work during OS deployment.

Did you ever get this sorted to be set higher during OS Deployment? It is causing us a few headaches here, out base software applications total well over the base 5bytes, also in a school environment

Has anyone got a definitive way to set the client cache size during OS deployment? The SMSCACHESIZE parameter is ignored during this process (news to me but it seems this is considered an upgrade, not a fresh install of the client...) and as a school, our deployed applications significantly exceed the bse 5GBytes (over 15GByte at present on some PCs). Is there a way I can set the cache to a larger size during deployment? I can't find anything that seems to work via Google as yet.

If we rebuild an existing computer to the same name as it previously had before, so it therefore SCCM should recognise it straight away, am I wrong in expecting the computer to know from the instant the build completes, which applications are deployed to it/the collection(s) it is in through SCCM? At the moment this doesn't seem to be happening as expected - computers pick up apps which are deployed to the 'All Windows 7 PCs' group that covers every PC we have (all this OS) but applications deployed to any sub groups (e.g. 'ICT Suite') seem to take a random amount of time, if at all, to ever be pulled down and installed. We have suitable maintenance windows and I've even tried manual action runs from the SCCM client Control Panel app, all to no avail. Am I missing something here, or am I just being impatient?

Cheers all - second boot trial and PXE didn't black screen so the error appears to be a one-off as I can't replicate it. Win7 32bit driver is working nicely, trialled a few bulds now and have all appropriate drivers within SCCM so Device Manager is happy once Win7 is installed

I have just tried the Win7 32Bit driver which appears to be working - during the first part of PXE boot it black screen errors to moan about a device no longer being found, but if you tap a key to continue it prompts to PXE boot which is so far working as expected. Not sure what the black screen error relates to, any thoughts?

If we can't use PXE, is there any way we can use an alternative deployment method via SCCM instead of manual installs? We're using Win7 Enterprise x64 exclusively. Thanks

Having tried loads of options from Google I am still stuck - we have a large number of very new Intel based desktops with the 82579v NIC on board - any one I try to download for this card and add to the MDT deployment boot image will not inject. PXE boot won't work, it gets to the first part after it loads the base image then crashes out and reboots, I never get to any of the deployment screens.Help welcome (no idea why this won't let me put in carriage returns? (Win8/IE1 in desktop mode).

I'm now testing OS deployment via MDT/SCCM, as the two stations we've had fail we just used the restored factory image - we'll see if this sorts it out or not After sorting the appropriate Windows NIC driver package out it is now just installing Windows Updates as part of the deployment process so I'll soon know if it is working correctly We'd tried manually updating the collection but even then, the station never picked up correctly.

Has anyone got any thoughts? This is pretty much the only thing within SCCM we now have to 'suss out' in our school, the rest of it appears to be working superbly

We've been using SCCM 2012 in production since July this year. The only issue we've really hit so far is when a computer OS fails and it needs to be re-installed. We first did this without touching SCCM, however we found that SCCM did not pick the computer up and install the client software (and Forefront) as previously worked when the computer was first commissioned. We did a manual client/Forefront install and SCCM does now show the computer, however none of the allocated applications have gone on. The next one that needed rebuilt we deleted the computer from the AD and SCCM before re-joining the computer to the domain (same computer name). Again, it did not get picked up by SCCM. Is this expected behaviour or are we missing some steps somewhere?

Hi all, we use SCCM 2012 in a school environment. We have our Windows Updates deployed during lunchtimes to avoid interruption to lessons, however we have not found a way to prevent the pop-up restart messages from appearing once any relevant updates have been installed. So far as I can find, my only option to prevent the messages appearing is to set the appropriate GPO to remove all balloon notifications from the system tray, however I am unsure if this will cause SCCM to reboot the computers without warning, or whether setting this will remove all messages and ensure that computers do not restart until their scheduled time after school hours.

Found one for me, in that changing the Recovery Mode of the Report database to 'Simple' removed most of the size.

Could you update us on how you resolved this please?

I have sussed it using the command line: "ie9-windows7-x64-enu.exe" /quiet /closeprograms For us, this allows IE9 setup to download and install the pre-requisites, whereas previously I was using the /no-updates switch.... Possibly not the correct way but it works!

I've been trying to get IE9 deployed via SCCM and have so far failed. Silent install from exe didn't work, I then used the IEAK software to create an MSI - I can do a silent install on the command line but it fails through SCCM still... Any advice?

Could someone clear this up for me please: We store any software packages that we wish to roll out with SCCM on a local drive on our SCCM server. The relevant folder is shared so we can access it from networked computers. In SCCM, when we create a new application, we point it to the relevant sub folder for the content location. When the wizard completes, and we then distribute the content, does SCCM take a copy of these files into its own storage structure so we can then delete our storage folder, or does it distribute the content from our folder meaning we have to keep it? If it does distribute from our location then I presume there is no reason why we cannot make changes to the files etc. within the folder e.g. modify a transform file slightly etc.? If it takes its own copy of the files then beyond recreating the application in SCCM, is there any way to integrate such minor changes into an existing application? Thanks for any replies