tregelen

I always remove the expired/superseded updates from my groups. This is because all of these groups will be installed on freshly imaged machines and you don't want an expired/superseded update being deployed. Also from my understanding the updates wont get removed from the database until they are no longer actively being deployed. Also I prefer to see all green rather than yellow/red/black.

You're right, you need to allow for the database to refresh. The following worked for me in a test. $MAC = "00:29:15:80:4E:4A" $PCName = "TESTPC" Import-CMComputerInformation -CollectionName "All Systems" -ComputerName $PCName -MacAddress $MAC while (!$ResourceID) { $ResourceID = $(get-cmdevice -Name $PCName).ResourceID Start-Sleep -Seconds 5 } Add-CMDeviceCollectionDirectMembershipRule -CollectionId 00100120 -ResourceId $ResourceID

Do you have any GPOs set that would change the cache size/location? Or even a GPO for the client installation? What is leading me to think that is that if you were using the default settings the cache would be set to C:\Windows\CCMCache and the size would be (correct me if im wrong) 4 GB.

Have you ticked the 'Disable 64-bit file system redirection'? I don't know if it will help but all of the uninstall TS that we have here have that ticked (I personally haven't created any as they were all done by my predecessor)

We use 1511 CBB and LTSB here and are evaluating 1607. We have around 40 public facing kiosks which are the only ones that run LTSB.

I found that I was having this at the place I work now. When I started they had already created their base image for Windows 7 and Windows 8.1 and had left the client installed inside that WIM. There were always issues with imaging until I removed the custom WIM and used the install.wim from the base ISO. Once I did that we haven't experienced that issue again. Maybe see what happens with the base wim.

It could be one of those weird things that are the reasons why MS doesn't recommend software installs with TS. Sorry I couldn't help any more.

My first thought is to bring up a brand new server and start from scratch. It would be much easier to install a new, fully functional system that it would be to reverse engineer someone elses mistakes and try to correct them. You can use the came content database and import the TS/Apps from the other system (although if you aren't using the PS App Deploy Toolkit for your apps I would suggest changing over). Install a new WSUS and sync that up and start moving the clients over. Will it have the same site code if you do this? No, it wont. You will need to create a different site code for the new system but in the end that isn't the worst thing that could happen. If you must keep the same infrastructure I would remove WSUS completely, delete the DB, remove everything and reinstall WSUS and create a new DB. Again, too hard to fix especially when its not documented.

Are you able to get away from TS at all? You could always use the PS App Deploy Toolkit (http://psappdeploytoolkit.com/) to handle the steps, as for the restarts you could use the prerequisites abilities with the Applications. As for why the TS aren't working what are the logs saying?

I have them never changing the password if they are service accounts otherwise you run the risk of forgetting to change the password in your console and having your deployments break. I keep track of them in KeePass and have that create a random password.

Agreed. If you can get rid of VPN and put in DA that will make things a lot easier for you.

Are the machines already in your database? You could create a collection based on each of the OUs and assign a collection variable to those collections. Where I work we have a collection for each OU so we can deploy OU specific software and I can easily define a variable to those collections. Those will be readable inside of your TS so you have the 'TRUE' set on whichever OUs actually require the file.

I was having a similar issue on my Server 2012 WSUS and it turned out that the company that does all of our server patching for us didn't complete the after installation steps for KB 3159706 https://support.microsoft.com/en-us/kb/3159706. Maybe there is a Server 2008 version of that update.

The first thing that comes to mind is your discovery method, how do you have your discovery methods set up?

I was able to work out my issue. As I don't normally have access to the switches I couldn't check the settings that tech support enabled, they applied to config but forgot to save and when there was a power outage the settings reverted. The settings were set again and saved this time and now everything is imaging fine. eltham: If you are deploying to unknown computers make sure that the MAC isnt in SCCM somewhere. Also check to see if the deployment is required, if not you have to be pressing Enter while it boots to do the network boot (the old F12 while PXE).

I am also experiencing this issue with the Surface Pro 3. I am able to PXE other devices but unable to UEFI boot machines as of Wednesday (was working before that)