Peter33

Have a look at this: http://technet.microsoft.com/en-us/library/gg712701.aspx#Support_Internet_Clients Probably the only way to go to accomplish your requirements. You can only define one update source for the wsus Clients. You can't compare this. Take Endpoint Protection for a comparasion, where you can define also several update sources.

SQL Management Studio.

OK, stupid question. You did not reuse the site code for 2012, did you?

You could create a new collection which holds all Clients which have not updated their policies during the last 24 hours or so. Then reinstall the Clients via right click on the collection (always reinstall). With SCCM 2012 R2 there also will be new Option to uninstall the Client before installing. Unfortunately it's just a prewiew now.

Nope, That's not clean. Check the mpmsi.log and mpmsi.log.lasterror. Anyways, i would just remove and reinstall the Management Point role to see if that will fix the Problem. <06/12/13 11:10:16> Installing D:\Program Files\Microsoft Configuration Manager\bin\x64\mp.msi CCMINSTALLDIR="D:\Program Files\SMS_CCM" CCMSERVERDATAROOT="D:\Program Files\Microsoft Configuration Manager" USESMSPORTS=TRUE SMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=63 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1 <06/12/13 11:10:38> mp.msi exited with return code: 1603 <06/12/13 11:10:38> Backing up D:\Program Files\Microsoft Configuration Manager\logs\mpMSI.log to D:\Program Files\Microsoft Configuration Manager\logs\mpMSI.log.LastError <06/12/13 11:10:38> Fatal MSI Error - mp.msi could not be installed. <06/12/13 11:10:38> ~RoleSetup().

Is your Management Point installed correctly? Check the mpsetup.log and mpmsi.log on your Server. You should also have an entry for the Management Point in the System Management Container, not only a single one for the site. Do you?

As long as you do not activate the auto assignement for Clients you can run both environments even in the same boundaries. Use the SMSSITECODE property for Client push. I assume your site server is publishing correctly to the AD?

No, you don't Need to add the SQL Server. If you only run a single Primary Server, as it seems, one boundary Group is doing well enough. Check your Client logs (clientlocation.log ,locationservices.log , execmgr.log, smscliui.log). Alos check if the Client components are installed and enabled (Software Distribution Agent).

Did you create boundary groups for site assignment and Content Location? Did you also migrate the collections and deplyoments(advertisments)?

Hi Peter, thanks for sharing this extension. It's something from the "what we always wanted in Config Manager" category and pretty valuable. To get it running in the console i had to add the "-file" switch to the parameters section of the xml files. I also have a wish list already, if you don't mind and find some time to add it. 1) A new colum with the membership type (direct or query) in the general tab. 2) A new action button to remove the client from the selected collection(s), also in the general tab.

Run this powershell script with admin rights on on of those clients and see if it returns something that is not 0. If it returns one or more application names, delete and recreate the applications in the console. I had a similar problem on 10% of our clients when the deployment cycle stopped working all of the sudden. This had been caused by a application which had been copied from another one in the console. I do not use the ability to copy applications anymore since then and the problem did not occur again. [int]$countMissingDTs = 0 try { $Applications = gwmi -namespace root\ccm\clientsdk -query "select * from ccm_application" } catch { exit 1 } $AppsTotal = $Applications.Length foreach($App in $Applications) { $AppDT = [wmi] $App.__Path if($AppDT.AppDTs.Name.Length -eq 0) { $countMissingDTs = $countMissingDTs + 1 $AppDT.FullName } } $countMissingDTs

Hi papa, i would suggest to use the Microsoft Deployment Toolkit. Here is Nialls Howto for Integration. If you read thru and finish the Integration, here is a customsettings.ini example which will create a Computer Name according to your Needs. Of course you have to fill up additional sections for your Hardware types and to remove the Gigabyte section (probably not the Lenovo section) Also use the Serial number instead of the asset tag, which is not always filled. [Settings] Priority=Desktop,Default Properties=MyModel,MyType [Default] Mytype=LP MyModel=%MAKE% OSDComputerName=#Replace("#Left("%MYMODEL%",2)#"," ","")#-%MYTYPE%-#Replace("#Left("%SERIALNUMBER%",7)#"," ","")# Subsection=%MAKE% [Desktop] Subsection=Desktop-%IsDesktop% [Desktop-True] MyType=WS [Gigabyte Technology Co., Ltd.] MyModel=GT [LENOVO] MyModel=LV

Hi Jameer, history views are starting with v_HS_. So you could use v_GS_INSTALLED_SOFTWARE and v_HS_INSTALLED_SOFTWARE for deltas. That's how the hardware histrory in the resource explorer is being computed.

You can also activate the wmi class in your hardware inventory. In the default settings it is disabled. This would mean less overhead for server and Client.

Seems your Client has some DNS problems. Dou you publish the DNS Suffixes with DHCP? Try to use the DNSSUFFIX property in your client push arguments.

How about using the corresponding histrory view.

Just create a Group Policy for these mchines which prevents the users from executing the scclient.exe.

Just create a new global condition and then use this in requirements tab of your deployment type as custom rule. This way you can make sure that the application only gets installed if the patch is already installed.

You don't need a 64 bit boot Image to install a previously captured 64 Bit Image, as long you don't use UEFI boot. My advice: use MDT2012 and create a new MDT Task sequence. It has some built in steps for partitioning, even depending on your boot procedure (UEFI/Legacy). You could also simply a "clean disk" step to your Task sequnce just before the partitioning step.

What is the filter rule released or revised during last day good for? This will only work if you create a new update group with every execution of the ADR. If you are using a single update group for the ADR this will mess it up. Rather add another option to remove superseeded updates.

What you seen in the "installed updates" list is just a history which is pulled from the database. It has nothing to do with what is actually injected to the WIM file. If you use the bak file you have to create a completely new Image in the console. Then rerun the scheduled updates Task. After that you have to update the distribution points. Otherwise the updates are only in the source file.

Hi Sam, yer welcome. WMF3 requires to have .NET4 installed. Otherwise it will fail to install. Rather use .NET4.5 though because it will replace also the infamous .NET4 Client Profile. Only one Version now in 4.5 (except the SDK Version of course). The Manual install probably works because it doesn't use any WMI calls, like the scripted SCCM Installation.

This is a "file not found" error. What does your cmd look like? My advice for Batch files: always use "pushd %~dp0" as your very first line and "popd" as last line. Make sure that your copy/xcopy command is correct. Also make it multi platform by using switches for x86 and x64 systems.

Hi Sam, since the repository repair didn't work your WMI itself seems to be broken. First thing would be to find out what your 10 Clients have in common. Like a package a or application that is only deployed to them. Maybe some snapshot Installation with unwanted registry keys, which are messing up the WMI on the Clients. It's hard to believe that the Clients randomly break without any reason. You can also try to install WMF3.0, if not already installed, to see if it will fix anything. The final solution would be of course the reimaging. But without knowing the source of the problem, it's more like a woraround than a solution.

No, the is no such Integration. We will just create a new deployment for the target collection and delete the test deployment.