boyjaew2

Thanks! I guess another question I should ask would be how does the windows client/config man client become aware of this change after the fact? I see the logic here, but after the package has been deployed, and the content has been removed from the ccmcache folder on the client-side, do I import the product code and wait for the ccm client to be polled again or do I have to update the content from sccm? I just tried this on the problematic win 7 client and it didn't seem to help. The adobe updater still failed to find my custom msi. Of course it did because it has been removed from the ccmcache at this point. The way I got around this was pointing the installer to the original msi on the DP. Then it was happy to proceed and updated just fine. Did I just not allow enough time or did I miss a step?

I imported the products on both deployments - package and application - as I'm not sure which method was used for this user. Will post results.

I have not, but I will. Does it make a difference that it is technically a package and not an application? That would direct it to my sources folder, I assume this uses the same permissions it used to push the original out in the first place and also that it DOESN'T matter that the original is missing from the cached content in the ccmcache folder? Thanks for taking the time to suggest a fix. I really appreciate it.

I am wondering if anyone has ever run into the following scenario: Java and Adobe both deployed VIA sccm 2012 can't be updated/upgraded. The install will fail referencing the ccmcache folder that held the original install bits, .msi. Usually the cache has been emptied and an error message pops up saying something like adobe.msi at "C:\Windows\ccmcache\e" can't be found and the update or upgrade fails. The only way around this that I have found is to run the MS Fixit program to clean out the registry entries for said program and run a completely fresh install of the application in question. Like I said it has happened with both adobe and java at this point. Does anyone know a good way around this and/or a way to avoid this in the future. Thanks!

Thanks, Niall. I appreciate it!

Hey all, Is there a super detailed tutorial for USMT someone can point me to? I'm getting ready to experiment with this for the first time using SCCM 2012 R2. Previously I have used the hardlinking method to do in place upgrades from win xp to 7 using a USB and some scripting, but have no clue how to utilize sccm in this regard. My goals are to be able to do in place OS refresh - same hardware, OS refresh from win 7 to win 7 without having to migrate files, settings and install programs again manually - I think I was able to do that previously. It's been a while though. I could be wrong about not having to re-install software. Secondly, a migration from old hardware to new hardware, same OS (win7 to win7) with the same caveats in mind - saving files, settings and applications. Lastly, an in place upgrade - same hardware upgrading from win 7 to win 8.1 with the files, settings and applications not having to be done manually. Like I said I have no idea what the prerequisites are and no clue about the process. I run sccm 2012 R2, I have WADK for 8.1 installed (don't know if that's important), in my sccm console I'm showing USMT tool for win 8.1 version 6.3.9600.16384, config manager client upgrade version 5.0, nothing built under User state Migration and no packages or task sequences related to this process. Super noob in this area. I would really appreciate any direction, thanks!

Agreed. Thanks

Interesting. Thanks! In your experience could this be leveraged as a vulnerability?

This - unixUserPassword: ABCD!efgh12345$67890 - Why is this set on some users in an environment with no SAMBA or unix systems?

Can someone tell me what the "unixUserPassword" attribute on a user account is used for? Another admin happened to run across this setting on a couple of user accounts in ADSI and it has a clear-text password set. It makes NO sense to me why this would be the case and only on a few user accounts. This seems very strange to me as we have no unix systems in our environment. What the heck?

[ciamgr.log] wrong log. :| Still looking.

After hours of trying to figure out why the "Add Computer Group" option on our main wsus server was greyed out after a new RODC deployment. It was discovered someone had changed our main WSUS server's settings to be "a replica of an upstream server". An obvious oversight on my part, but was distracted by other issues caused with the newer server. In order to help a newer admin understand why that is not a good setting to mess with on the "master" DC I first wanted to make sure when and by whom it was changed. I can't seem to easily find any indication in logs. Is this something that can be discovered? If so, can someone please help me out? I am starting with ciamgr.log, if I can find it, but please let me know if you have a good idea about how to accomplish what I'm trying to do. Thanks WHY did I post this here? Sorry about that. MOD, feel free to delete this post.

Okay, a couple of gotchas. 1) I shouldn't have built the custom share. Just check the "copy the content in this package to a package share on distribution points". Also, something I don't quite understand. 2) I had to create a new package for the Configuration Manager Client and point to that in my OSD task sequence. If you don't do this when you go to deploy the task sequence you will not get the "Deployment Option" - "Access content directly from a distribution point when needed by the running task sequence". I am now successfully deploying the image in the task sequence from the remote DP, not pulling the image over the WAN link. Thanks for all the feedback and help, rocket man. I really appreciate it.

Standby...I think I answered my own question.

Dang it. Looks like I spoke too soon, still pulling image from primary DP over the internet. I had decided to go with the "Copy to share" option and created a custom share. I thought that would do the trick. I currently have nothing in my SMSPKGW$ directory - thanks for that info by the way - Should I NOT have created the custom share (PackagesFromSccm12$\Images)? What do you think? All the bits for the OSD are on the remote DP, but maybe in the wrong place? Man, this is confusing. I feel like a damn idiot. Below are the settings for the .wim Data Source settings Distribution settings

Rocket Man, Thanks, for helping me get this thing sorted.

Thanks for all the help. I really appreciate it. This all makes sense. I think I have it sorted for the most part and it looks like adjusting some of the settings on the various packages under "Distribution Settings" and on the remote DP distributon point settings - "Enable this distribution point for prestaged content" is what was giving me issues. I didn't have these setup correctly. So, the remote DP was waitng for prestaged content and the packages were all set to "Manually copy the content in this package to the distribution point". After I got those straightened out, at least, the actual distribution was succesful. I've yet to test the image deployment, but I think it will work now. I have to test tonight and hopefully I can follow up with a note of success. One thing I've never been quite clear on is: when you set up WDS (via turning things on in sccm) it builds all those folders - RemoteInstall, SCCMContentLib,SMS etc. And, the share names don't help matters much. I've never been very clear as to what goes where. For example the obvious choice in my mind for where to see the images I build is RemoteInstall\Images. Yet, nothing ever ends up in that folder on either site. If you could either tell me where to look to confirm where the CCM00055.wim is on the remote DP or point me in the direction of some solid dox on the matter, that would be very useful to me. I see .ini files and what look like hashes for it, but not the full 8GB .wim anywhere.

Yes, I have distributed the image package from the primary. Is that the wrong way? I think I must be misunderstanding what happens. I thought by distributing the content, among other things, I was sending all the actual content over to the remote DP so that they'd be local to that site when I ran my task sequence. I was thinking about that though and if the UNC path for the image is the local DP then that IS probably where it's going to get it from. Which is what I don't want. We have a 10mbps MPLS link bewteen sites, but my goal was to have all the big stuff, like the image.wim, already sitting at the remote DP site. I DO NOT want to be pulling images across that link. So, do I have to build a new task pointing to the remote DP for the .wim or go with the prestaged content? I have not created a prestaged content file before, but that kinda sounds like what I'm trying to do. smsts.log from test image task: I bolded the parts that especially confuse me. Will creating a prestaged content file make the .wim available locally? Should I move the .wim manually to a specific folder on the remote DP? Where is that "DownloadOnDemand" flag set? Command line for extension .exe is "%1" %* TSManager 4/7/2014 5:10:47 PM 648 (0x0288) Set command line: OSDApplyOS.exe /data:CCM00055,%OSDDataImageIndex% TSManager 4/7/2014 5:10:47 PM 648 (0x0288) Start executing the command line: OSDApplyOS.exe /data:CCM00055,%OSDDataImageIndex% TSManager 4/7/2014 5:10:47 PM 648 (0x0288) !--------------------------------------------------------------------------------------------! TSManager 4/7/2014 5:10:47 PM 648 (0x0288) Expand a string: WinPE TSManager 4/7/2014 5:10:47 PM 648 (0x0288) Executing command line: OSDApplyOS.exe /data:CCM00055,%OSDDataImageIndex% TSManager 4/7/2014 5:10:47 PM 648 (0x0288) Command line for extension .exe is "%1" %* ApplyOperatingSystem 4/7/2014 5:10:47 PM 2020 (0x07E4) Set command line: "OSDApplyOS.exe" /data:CCM00055,1 ApplyOperatingSystem 4/7/2014 5:10:47 PM 2020 (0x07E4) Searching for next available volume: ApplyOperatingSystem 4/7/2014 5:10:47 PM 2020 (0x07E4) Volume C:\ is a valid target. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Found volume C:\ ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Windows target partition is 0-1, driver letter is C:\ ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Succeeded loading resource DLL 'X:\sms\bin\x64\1033\TSRES.DLL' ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) The machine does not have a local client cache. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) ResolveSource flags: 0x00000000 ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) SMSTSPersistContent: . The content for package CCM00055 will be persisted ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) DownloadOnDemand flag is true. Attempting to download content locally for Package CCM00055. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Locations: Multicast = 0, HTTP = 1, SMB = 0. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Package Flags: 0x01000000 ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) And we're off to the races at this point pulling across the WAN. Multicast is not enabled for the package. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Trying http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/CCM00055. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) GetDirectoryListing() entered ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Initializing HTTP transport. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Setting URL = http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/CCM00055. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Address=http://SCCM12.mydomain.com, Scheme=http, Object=/SMS_DP_SMSPKG$/CCM00055, Port=80. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Setting Authenticator. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Set authenticator in transport ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) WinHttp credentials set ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) CLibSMSMessageWinHttpTransport::Send: URL: SCCM12.mydomain.com:80 PROPFIND /SMS_DP_SMSPKG$/CCM00055 ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) 401 - Unsuccessful with anonymous access. Retrying with context credentials. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Using thread token for request ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) 401 - Unsuccessful with context credentials. Retrying with supplied credentials. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Request was successful. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) DAV response string is: <?xml version="1.0" encoding="utf-8" ?><D:multistatus xmlns:D="DAV:"><D:response><D:href>http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/sccm?/CCM00055/</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><D:getcontenttype/><D:supportedlock/><D:getetag/><D:creationdate/><D:iscollection>1</D:iscollection><D:resourcetype><D:collection/></D:resourcetype><D:ishidden>0</D:ishidden><D:displayname>http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/sccm?/CCM00055/</D:displayname><D:getlastmodified></D:getlastmodified><D:getcontentlanguage/><D:getcontentlength>0</D:getcontentlength></D:prop></D:propstat></D:response><D:response><D:href>http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/CCM00055/sccm?/Elitebook%20840%20G1.wim</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><D:getcontenttype/><D:lockdiscovery/><D:supportedlock/><D:getetag/><D:getcontentlanguage/><D:iscollection>0</D:iscollection><D:creationdate/><D:resourcetype/><D:ishidden>0</D:ishidden><D:displayname>http://SCCM12.mydomain.com/SMS_DP_SMSPKG$/CCM00055/sccm?/Elitebook%20840%20G1.wim</D:displayname><D:getlastmodified>Tue, 01 Apr 2014 15:53:11 GMT</D:getlastmodified><D:getcontentlength>9076271985</D:getcontentlength></D:prop></D:propstat></D:response></D:multistatus> ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) List of files to be downloaded ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) File: http://SCCM12.mydomain.com:80/SMS_DP_SMSPKG$/CCM00055/sccm?/Elitebook%20840%20G1.wim ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) GetDirectoryListing() successfully completed ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Succeeded loading resource DLL 'X:\sms\bin\x64\1033\TSRES.DLL' ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) 401 - Unsuccessful with anonymous access. Retrying with context credentials. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) 401 - Unsuccessful with context credentials. Retrying with supplied credentials. ApplyOperatingSystem 4/7/2014 5:10:48 PM 2020 (0x07E4) Downloading file /SMS_DP_SMSPKG$/CCM00055/sccm?/Elitebook%20840%20G1.wim range 0-2147483646 ApplyOperatingSystem 4/7/2014 5:10:49 PM 2020 (0x07E4) Executing command line: X:\WINDOWS\system32\cmd.exe /k TSBootShell 4/7/2014 5:14:12 PM 764 (0x02FC) The command completed successfully. TSBootShell 4/7/2014 5:14:12 PM 764 (0x02FC) Successfully launched command shell. TSBootShell 4/7/2014 5:14:12 PM 764 (0x02FC) Thanks again for the help.

I see. Yes, I robopcoy'd JUST the sources folder and from what I gather this was unnecessary and probably a bad idea. Moving forwad it sounds like I want to remove the SOURCES folder from the remote DP and double check the fallback option on the task and make sure it's not failing over to the PS DP. About the .wim not being present, should I just wait for the distribution task to workitself out pending the SOURCES folder removal? It seems like it's trying everyday. Or is there another step to get the wim properly distributed? The driver packages and boot images all moved successfuly from what I can tell. The image DID complete. It just pulled 9GB over our WAN to do it.

I have set up a distribution point for a primary site. Remarkably I didn't have to fuss too much to get PXE to work. What I'm seeing now though, is an unknown client will PXE fine from the distribution point location which is in the proper boundary group, but then it will the image.wim in the task sequence across the WAN rather than locally. I have WDS up and running on the DP and have distributed successfully (from sccm primary to DP) everything included in the task sequence other than the image.wim for the task. I get "failed to distribute content" under Distribution status, but see nothing failing in distmgr.log, but I also never see it actually adding the package to the DP, just the primary site location. This is a snip from the most recent attempt in distmgr.log which has been queued for about 4 days, but doesn't succeed. Found notification for package 'CCM00055' SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 6236 (0x185C) Used 0 out of 5 allowed processing threads. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 6236 (0x185C) Starting package processing thread, thread ID = 0x1154 (4436) SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 6236 (0x185C) Sleep 3600 seconds... SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 6236 (0x185C) STATMSG: ID=2300 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=SCCM12.mydomain.com SITE=CCM PID=4068 TID=4436 GMTDATE=Mon Apr 07 17:13:27.909 2014 ISTR0="Elitebook 840 G1" ISTR1="CCM00055" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="CCM00055" SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 4436 (0x1154) No action specified for the package CCM00055. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 4436 (0x1154) Start validating package CCM00055 on server ["Display=\\goldendp.mydomain.com\"]MSWNET:["SMS_SITE=CCM"]\\goldendp.mydomain.com\... SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:27 AM 4436 (0x1154) DP health monitoring task has been started successfully to verify package 'CCM00055'. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:28 AM 4436 (0x1154) Package CCM00055 does not have a preferred sender. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) The package and/or program properties for package CCM00055 have not changed, need to determine which site(s) need updated package info. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) CDistributionSrcSQL::UpdateAvailableVersion PackageID=CCM00055, Version=2, Status=2301 SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) StoredPkgVersion (2) of package CCM00055. StoredPkgVersion in database is 2. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) SourceVersion (2) of package CCM00055. SourceVersion in database is 2. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) STATMSG: ID=2301 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_DISTRIBUTION_MANAGER" SYS=SCCM12.mydomain.com SITE=CCM PID=4068 TID=4436 GMTDATE=Mon Apr 07 17:13:29.764 2014 ISTR0="Elitebook 840 G1" ISTR1="CCM00055" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=400 AVAL0="CCM00055" SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) Exiting package processing thread. SMS_DISTRIBUTION_MANAGER 4/7/2014 11:13:29 AM 4436 (0x1154) I have a volume on the DP dedicated for WDS which includes the following directories: RemoteInstall, SCCMContentLib, SMS, SMS_DP$, SMSSIG$ and a SOURCES folder which I robocopy'd relevant folders and files needed for OSD at the DP location from the primary site server. I set all permissions the same on both sets of folders; the ones on the primary site and the DP site. I'm wondering if I have the task sequence wrong? I thought the OSD TS was supposed to use content closest to the client, but do I have to build a new TS to point to DP content - SOURCES folder on DP - or should the content from the SOURCES folder be in a different location on the DP i.e. RemoteInstall folder or something? The imaging task actually succeeds, much to my amazment, but as you can imagine, I don't want that running over the WAN. Thanks in advance for any input,

Thank you so much! Very cool idea by the way.

Peter, This looks to be just what the doctor ordered. The problem is, I'm pretty new to powershell. Do I need to go through the script and provide site, collection, site code and server manually? If you have time to provide a brief example it would really help me out. I appreciate your time. Thanks.

This error has returned. System has not changed. I will try what I did before, but any input would be great. Thanks

Was able to have a DBA dig this up. I don't know if it helps me much, but could it have something to do with my "Delete Aged Endpoint Protection Health Status History Data" Site maintenance task? Keeping in mind the above comment of course. -- Stored procedure throwing the error spSummaryTaskEPSecurityHealthDashboard -- Gets a list of Collections and Clients from: SELECT * FROM vEPCollections -- and SELECT * FROM CollectionMembers -- Performs MERGE statements against these 5 tables SELECT * FROM EP_EndpointProtectionHealthStatus SELECT * FROM EP_EndpointProtectionHealthStatus_History SELECT * FROM EP_TopThreats SELECT * FROM EP_ThreatPath SELECT * FROM EP_ThreatCleanActionState

SCCM 2012 SP1 Beta SQL 2012 Server 2012 Stand alone primary I am NOT a SQL guy and I am getting a persistent and vague error on my sccm 2012 server. "Microsoft SQL Server reported SQL message 8672, severity 16: [42000][8672][Microsoft] [sql Server]The MERGE statement attempted to UPDATE or DELETE the same row more than once. This happens when a target row matches more than one source row. A MERGE statement cannot UPDATE/DELETE the" Message ID: 620Process ID: 2232Thread ID: 4920 I get an error about every 6 minutes or so. What I have read so far indicates a possible duplication in a table somewhere. What my SQL people have told me is "looks like there's an error somewhere". Then tell me you have to know the table your looking for and that even if you find it there will be nothing obvious to tell you what needs to be fixed let alone HOW to fix it. So, I'm super stuck. I know next to nothing about SQL, but if some one has seen this before, if you could help me out that would be great! I have tried simply clearing the counter. I'm sure you can imagine how much that helped. Thanks,