Peter33

Open your SCCM Console and go to the Administration Section, Serurity, Accounts. Check if the Domain Admin is in the list of the accounts. Sounds pretty much like they used is as Network Access account. Where exactly Fails the TS? Right away or at the "apply Network Settings" step? Check this step in your TS if they used the Account for Domain join.

nslookup -type=srv _vlmcs._tcp Check if your client can resolve the KMS Service. Like Jorgen said, you don't have to do anything if KMS is configured correctly. Also restart your KMS Server. Check if you have already reached the necesssary number of clients for activation.

@joeman: Yep, that's pretty strange. are all the clients from same vendor and same build? @Ocelaris: That's also a good solution as long you don't have to set local admin rights for users on single machines.

In SCCM Packages, ADRs etc, you find the Setting in the "download settings" tab. (Allow Clients to share Content with other Clients on the same subnet) For your Windows Clients it's most likely configured via group policies (Computer Configuration -> Administrative Templates -> Network - >Branch Cache). You can check on your Clients by using the RSOP or GPRESULT commands.

<OOBE> <HideEULAPage>true</HideEULAPage> <HideLocalAccountScreen>true</HideLocalAccountScreen> <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen> <HideOnlineAccountScreens>true</HideOnlineAccountScreens> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> <NetworkLocation>Work</NetworkLocation> </OOBE> No, that's a completely different issue. You have to modify your unattended.XML file (oobe section) to disable this step.

Sorry forget about that I was totally out of my mind. You have the Thin Clients enabled by listing them in there. You just have disabled to discover objects within groups. If you dont's want to discover this OU, do not refer to it in AD System discovery.

I am using a normal package, without a program, which holds several deployment scripts. In the task sequence i am using a command line step with this command: powershell -executionpolicy bypass -file ".\scriptname.ps1" This has the advantage that you can run the script with a different user account, for example to create AD objects or to modify AD group memberships.

Actually you AD System discovery should discover nothing, because you have not configured a valid target container. You need to define an include, to get this working. Your whole discovery is done by the group discovery at the moment. You should be kinda restrictive with group discoveries too. Also check you Server logs (adsysdis.log adgdis.log). That's the place to start for trouble shooting.

$group.Add("WinNT://MYDOMAIN/MYGROUP,group") No problem. You just need to edit the last line, according to the name of your own AD group. So if your group game is like MYDOMAIN\MYGROUP, the last line would look like this.

It takes the same bandwith as normal applications/packages in SCCM depending on the number of the required updates for the Client. The Client will only download the required updates, even if the update package cotains all updates for a product. This should have no Impact on your Clients Performance at all, except you have set some insanely short schedules for scan and retry. A different Story is, when you just have activated SUP on your Environment, and the clients start to compile all the policies for the published updates. This may take a while and indeed affect the disk IO on clients for several minutes. Every single published update represents a single policy which has to compiled and registered. You can actually see it in the logs. We have like 5000 published updates and a fresh Client takes like 20-30 minutes, until all policies are avaluated. That's a lot of overhead on the Client even without debug logging activated. Anyways, i doubt that your problem is related to it. Do you have Branch Cache activated on your clients?

$objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-544") $objLocalGroup = $objSID.Translate( [System.Security.Principal.NTAccount]) $strAdminGroup = ($objLocalGroup -split "\\").Get(1) $group = [ADSI]("WinNT://"+$env:COMPUTERNAME+"/$strAdminGroup,group") $group.Add("WinNT://DOMAIN/GROUPNAME,group") Do not use this command to add Domain users/Groups to your local Groups. The command has a bug and will fail if the name length (including the Domain) exceeeds a specific number of chars (think it was 22?). I am using a powershell script to add local group members (the above script: language neutral for the local admin group).

Have a look at this, and also check out the other posts in his blog. This will will give you a better understanding of the Windows Update Agent and of SCCM update processes. http://blog.configmgrftw.com/software-updates-management-and-group-policy-for-configmgr-cont/

Did you also check the limiting collection of your deployment collection?

Let me take a wild guess. Your Office 2010 is part of an optional task sequence (probably OSD). And your Adobe Reader obviously too. If you superseed an application, which is part of an optional task sequnce, all clients of the task sequence target collection, with the superseed version installed, will get the new Version, no matter to which collection you deploy it. Makes sense? No .. but it's the sad truth. I actually had a ticket open with MS Support. They could'nt help us either. The bug seems to have no priority for the developers and might be fixed with a future CU. I am hardly using the supersedence option anymore now, to avoid this bevahior.

How does your uninstall command look like? Are you using the same exe there? Try to uninstall with 'msiexec /x {productcode} /L*v c:\winodws\temp\myuninstall.log /norestart /q'. So if that fails you have at least a logfile which tells you whats going on.

Yes, we get no EULA, and the only parmeters we are using are JU=0 JAVAUPDATE=0 AUTOUPDATESCHECK=0 /norestart /q. Also forget about the mst file. It's not worth the effort of creating a new one every month.

Same here, where you though have to say that the update check properties are not really working anymore since version 7.

Exclude the update by defining a custom servirity in the properties. Then alter your ADR only to use updates with a custom servirity of 'none'. Finally crate a new Manual aupdate group, which only holds this KB and publish it to a new collection which excludes your 2 machines. On a site note. Do not use general collections for deployments, always create a new collection for a deplyoment. It will make you life easier when you want to exclude or include machines or collections from a deplyoment.

$ErrorActionPreference="Stop" $file = $env:LOCALAPPDATA + "Low\Sun\Java\Deployment\security\exception.sites" $servers = @( "http://yoururlhere.com", "https://anotherurl.net" ) if(Test-Path $file){ foreach($server in $servers){ if(!(Select-String $file -pattern $server)){return($false)} } } else{return($false)} return($true) You can do that by creating a compliance rule. Based on the deployment of the rule you can create compliant, non compliant and error collections. Here is a little sample script to check multiple strings against a local file.

I have just noticed that the automatic client repair task will reset the cache size to the standard value of 5 GB. One of our latest deplyoment with a size of 2GB failed on over than 100 Clients because of the cache size, which is set to 20GB on the clients. That got my attention and i checked the client logs, which showed that they had performed a client repair but without a value for SMSCACHESIZE. So this seems like a bug to me. Can someone confirm the behaviour? I fixed the problem for the affected clients through a remote powershell script, but that's no long term solution. Applications or Compliance rules are neihter a solution, because the applied WMI property has to be confirmed by a service restart. Otherwise the changes will be lost again. Maybe a scheduled task would do the trick, but i would rather like to see Microsoft fixing the problem. Regards Peter

if($uptime.days -gt 3){$wmi.Win32ShutdownTracker(300, 'provide a message for logged on users here.', 0, 2)} This would reboot a machine, which is running for more than 3 days, after 5 minutes grace and also show a message to a logged on user.

I am using a webservice (Maik Kosters) for AD queries. It's way faster and more secure.

We got the same issue since R2. I was actually analyzing the problem and found the reason, but no solution yet. For some odd reasons, the application is trying to access the file “C:\Windows\inf\setupapi.app.log”. That’s where the compatibility assistant is being triggered. I didn't open a MS support case though. Just waiting for the next CU.

The only downside is that your PE Image will be inflated to 300MB. So it takes a little bit longer to load. I also experienced some problems during the reimaging of some older bitlocker encrypted builds, because of the size of their BDE partitions. So i had to add an additional partitoning step (bitlocker command line ), which kicks in in case the BDE Partition is too small to keep the PE. Otherwise the Task sequence would just error out after applying the boot Image. New BDE partitions are getting formatted with 500MB now.

Just define a deadline far far far far far .... far in the future. Like 2050 or something. Edit: My fault, you can only define 12 month. But this should be good enough, because the deadline will be set again as soon as the ADR runs.