VRDRF

I just did a migration from MBAM to SCCM MBAM and wanted to share my findings, maybe its usefull to someone else. Everything worked for me except I wouldn't see any recovery keys in the SCCM database. There seems to be an issue where the MBAM recovery part in IIS is not working, SMS_MP_MBAM exists but if you click it you will get a "file not found" I realised this is a similair issue as Anyweb describes in the OP but its not exactly the same. The solution is the same, open the .cab file and extract it in for example "D:\Program Files\SMS_CCM\Microsoft BitLocker Management Solution" and run the mbamrecoveryserviceinstaller.ps1 script to set the acl's on the files. The recovery url should also be viewable after that, in my case that was https://sccmserverfqdn/SMS_MP_MBAM/CoreService.svc I also had to replace the old MBAM Recovery Service Endpoint with the new URL (https://sccmserverfqdn/SMS_MP_MBAM/CoreService.svc) to get clients to report the recovery keys to the SCCM database. This also causes existing MBAM clients to report their recovery keys again.

all reports 50% of the time, you then have to refresh the page to get them to work. the datawarehouse reports don't work at all, not even after a refresh and these are the only reports that this broken data source has dependent items for. You can also see that the connection string for this data source is not correct, I can change it but sccm just changes it back after I press apply.

Well I'm not trying to change anything, these 2 data sources are created by sccm every time the reporting point is installed by SCCM, one of them works and the other one doesn't. This is a fresh installation of SSRS on the same machine that is running the new SCCM installation, it is in no way connected to the old environment. Basically what I'm trying to do is to get rid of the broken Data source so that my reports will stop failing 50% of the time.

We have recently reinstalled our SCCM environment and migrated from the old environment to the new one. The problem is that it seems some of the reporting services datasources were also migrated to the new server and is now causing some issues in reporting services. reports sometimes fail because they are looking at a broken datasource that doesn't connect. Stupid thing is, the old environment has the exact same data sources and the same one is also broken there but isnt causing issues. The one starting with 5C works fine but the one with 39 just doesn't connect. We have tried: changing connection string (it works but sccm just replaces the string again causing it to break again) Removing data source (sccm will just recreate it and break all the reports) Reinstalling report point (sccm will just recreate all the reports and the broken data source) reinstalling ssrs (threw database and files away but result is the same) Now I'm guessing that SCCM just creates the datasources based on something that is in his database but how do we get rid of this? Thanks in advance guys!

Yeah I did. I managed to solve it in the end, for some reason the old sysprepped windows 7 didn't like the patch but a clean install.wim did. Removed the updates folder from the client folder and redistributed the package and it worked again. Now trying to find out what is actually in that sysprepped image apart from someone deciding it was a good idea to put office 2010 and adobe reader in the base image.

I tried doing that but it still fails for the same reason, I can see in the ccmsetup that the file is there so its not like like it can't find the update file.

I recently upgraded the OS of my SCCM server to 2012 R2 by doing a site recovery on a new OS and for some reason during the Windows 7 OSD install the update for the sccm client fails for no real apparent reason and to make it even stranger is the fact that My windows 10 and Server 2012 R2 work just fine with the same client package. I can see the following in the log files: configmgr2012ac-sp2r2sp1-kb3074857-x64.log: I've tried using the PATCH= Function but that doesn't seem to solve anything. Edit: found this in the ccmsetup.log:

What I quickly found while googling: http://support.microsoft.com/kb/555374 But that is for server 2003 SP1, what OS are you having this problem with?

As far as I know these packages are created each time you upgrade your sccm installation (Ive seen it before) They hold the new version of the sccm client. im not exactly sure if they all contain the same files, you would have to check the source for that. I'm guessing one is from rtm to sp1, second one from sp1 to R2 and the third from R2 to Cu3. You can safely move them to a sub folder as its just a visual thing in the console or delete them as long as you don't delete the one that has the latest clients version.

Just to check, you guys create a new folder for each update package right? So for example: \\ServerName\Updates\UpdatePackage1 \\ServerName\Updates\UpdatePackage2 \\ServerName\Updates\UpdatePackage3 etc As far as I know and you are free to correct me on this one but if you enter the same folder (\\ServerName\Updates)for all the update packages and SCCM's package validation comes around it will empty out the folder because the rest in there from the other packages should'nt be there.

Ive been trying to do the same but for our virtual machines running on esx 4.1 but the problem is that it looks like WDS is using some kind of windows 8 boot loader before it loads the winpe image so even if you use a winpe 3.0 boot image it still won't load.

We will need more information about the patch you are trying to deploy, like command line, query etc.

Does your boot image support HTA? We use HTA support in our environment by creating a package with the HTA in it and use a "run command line" in our task sequences, commandline looks something like "askforpcname.hta" and point to the package that has the HTA file.

A deadline will still be a deadline, even if the user could set it to 24/7 the updates will still install the moment the deadline is reached, business hours or not.