surfincow

Hello, I saw a question regarding not being able to use the traditional (and already most likely pre-created driver packages) but I'm curious if rather than creating multuple "download package content" and then creating additional driver package "packages" would it work to simply create multiple "Upgrade Operating System" steps that use the normal (and already created) driver packages and base that step on a wmi query for the model? Seems like an awful lot of work to make duplicate packages for drivers that already exist. Any idea why the normal driver package step does not work?

Hello, Went to install this hotfix earlier today and during the first try I received the following error from the Üpdate Pack Installation Status" window (the window under Monitoring > Site Servicing Status > $Update. it was a separate pop-up message) Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlQueryException: The SMS Provider reported an error connecting to the ConfigMgr site database server. Verify that the SQL Server is online and that ConfigMgr site server computer account is an administrator on the ConfigMgr site database server. ---> System.Management.ManagementException: This is odd because the previous upgrade to 1602 went fine and there hasn't been any change in Configmgr related accounts and also the prereq passed (however I was unable to locate the actual log showing any information). Restarted the console and it had the latest version. Everything looked OK but since I was not certain, I reverted to the snapshot takin before the upgrade. Didn't find much information online so decided to run it again, this time not having that status window running. Everything went through OK and looking at the "Show Status" for that update everything shows green (I don't believe anything showed red from the previous install but I can't recall for certain). CMUpdate log looks fine and only thing showing red is some things registering with .net. CTool::RegisterManagedBinary: run command line: "C:Windows\Microsoft.NET\Framework64\v2.0.50727\RegAsm.exe" "C:\Program Files\Microsoft Configuration Manager\bin\x64\wsyncact.dll" CONFIGURATION_MANAGER_UPDATE 6/27/2016 2:07:08 PM 9440 (0x24E0) CTool::RegisterManagedBinary: Failed to register C:\Program Files\Microsoft Configuration Manager\bin\x64\wsyncact.dll with .Net Fx 2.0 CONFIGURATION_MANAGER_UPDATE 6/27/2016 2:07:09 PM 9440 (0x24E0) CTool::RegisterManagedBinary: run command line: "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\RegAsm.exe" "C:\Program Files\Microsoft Configuration Manager\bin\x64\wsyncact.dll" CONFIGURATION_MANAGER_UPDATE 6/27/2016 2:07:09 PM 9440 (0x24E0) CTool::RegisterManagedBinary: Registered C:\Program Files\Microsoft Configuration Manager\bin\x64\wsyncact.dll successfully CONFIGURATION_MANAGER_UPDATE 6/27/2016 2:07:09 PM 9440 (0x24E0) But looks like eventually it registers. So I'm wondering then should I assume everything went OK, or is there anything in particular I could do to verify things went as expected?

Hello, I know the start menu can be customized during the OSD process, and through GPO (negative is GPO makes menu user non-editable), but is there a way to customize it post-install? We are deploying Office 2016/O365 and during the process the old Office 2013 start menu icons are removed. I'd like to be able to add the office icons to the start menu but not sure how to go about it. Any thoughts? (This is pushed via Configuration Manager so its installed as System for the machine rather than user installed). Thanks!

Yeah, this sounds like the process we use now. Updated driver at install time but after that they stay the same. It is good to get your feedback as if this isn't something others are doing then there's probably a reason Thanks!

Hello, I believe I'm soon going to be tasked with using configmgr to keep drivers up to date on all our workstations (all are Dell Latitudes). I briefly attempted this before using the Dell Business Client Updates Catalog for SCUP. The results were not as great as I had hoped. There is an agent you push to all the machines which collect what drivers are required. You also publish the meta-data from the update catalog to configmgr and then after a few days you can query to see what drivers are actually needed. The issue I ran into is that the update catalog contained numerous circular dependencies (example: To install UpdateA you must have UpdateA installed). The result of this is that even though none of these updates were deployed, they were in the updates db in configmgr which broke software updates for all configmgr clients. (they would fail due to circular dependencies). To find the problem was quite involved which required referencing numerous logs, expiring the update from SCUP, republishing, re-sync the software updates and try again. Lather, Rinse, Repeat. I believe I had at least 30 of these circular dependencies which took about a day to fix. Once that was resolved, the updates themselves weren't that "up to date" either. Since then I've been turned off by the Dell Update Catalog. I've worked with a few SCCM consultants (MVP's) and asked about how they handle driver updates at the places they manage (universities with 1000's of workstations), and their answer was "we don't". So I'm wondering, do any of you handle the updates of drivers? and if so, whats your method? Thanks!

"use a password on the task sequence itself" - is that separate than the bootmedia password? If so, do you have a link that discusses it? thanks

Hello, I'm wondering if its possible to limit which task sequences a user can run? We currently do workstations with ConfigMgr, but are looking to do servers as well. Since all available task sequences show up (when deployed to unknown computers collection) people who normally deploy the workstations can now also do servers. Is there a way to restrict access some how to allow those deploying workstations only those TS and servers only those TS? Closest thing I could find is this thread: https://www.windows-noob.com/forums/topic/6456-how-can-i-deploy-a-hidden-task-sequence-in-configuration-manager-2012-sp1/but I'm wondering if there is another way. Thanks

Yes, exactly like that I did try importing the .cab with the current client but it didn't work. MS also does not list this as available at least on the new version. I don't really like the client automatic upgrade feature (as a scheduled task), nor pushing out a package. Deploying it as an update from ConfigMgr (not WSUS) would be ideal. Is this still possible with CB?

Hmm.. I've not heard of this before and I just checked my smsts log from a newly imaged machine and do not see my network accounts there nor the accounts used to join machines to the domain. Are you somehow using some sort of script that contains the username and password of the network account? If so, that could be why they show in the log. Noticed that issue a few years ago trying to configure the BIOS on some dell workstations. One of the parameters is what we want the password to be. Since that's part of the command string it gets logged. Not very good security wise so we ended up using a different approach that didn't involve passing the password as a command.

Anyone know if its still possible to upgrade the client using this method? https://technet.microsoft.com/en-us/library/jj553405.aspx?f=255&MSPPError=-2147217396#BKMK_DeploySCUP

Hello, Is anyone using this feature for packages/applications? I have a scenario where this feature would come in handy, but I'm not finding any information about how to make it "unpersistable". Would simply removing that setting on the package and waiting for the clients to update allow the package to be removed like non-persistent packages? Or would the package be cleared out once the application/package is no longer deployed? Seems like it should be that easy but not coming across any documents stating that. Thoughts?

OK I believe this is fixed. The problem was with the client authentication certificate template compatibility set to 2008 rather than 2003. We just did a PKI upgrade and the original templates were to be copied "as is" to the new CA, so I had assumed this had been done. After further checking I noticed this was not the case. When the client registration was working using PKI it was actually using the old client authentication certificate from the old CA rather than the new since it was unable to view the private key. When I tried to install the client on brand new machines (that did not have the old CA client auth. certificate) it failed. After re-creating the template with the correct compatibility this problem has gone away. Thanks!

I'm not seeing "bug fixes" included in notes. Will bug fixes and feature releases be 2 separate items?

Hello, Having yet another strange thing popup with the new ConfigMgr. This appears to be a new issue that hasn't always been there. I had previously installed the client on a few machines without any problem. Now, I'm consistently finding any machine I try to install the client on receiving this error: Certificate [Thumbprint xxxxx] issued to 'computername.domain' doesn't have private key or caller doesn't have access to private key. I've found a few topics on this: -https://www.windows-noob.com/forums/topic/6607-ccmsetup-failed-with-error-code-0x87d00283/ -https://www.bibble-it.com/2012/10/14/sccm-2012-client-deployment-fails-in-https-mode There are more, but these two seem the most relevant. The 1st link looks like it deals more with Windows XP but I went ahead and checked the permissions on the keys and there are no permission issues. System and administrators have full control. I'm pretty much stuck and don't have any idea what might have caused this. The installation is all https so certificates must work. Here is the section of the logs where the errors are shown: The 'Certificate Selection Criteria' was not specified, counting number of certificates present in 'MY' store of 'Local Computer'. 3/18/2016 11:12:11 AM 8816 (0x2270) 1 certificate(s) found in the 'MY' certificate store. 3/18/2016 11:12:11 AM 8816 (0x2270) Only one certificate present in the certificate store. 3/18/2016 11:12:11 AM 8816 (0x2270) Begin validation of Certificate [Thumbprint xxxxx] issued to 'computername.domain' 3/18/2016 11:12:11 AM 8816 (0x2270) Certificate [Thumbprint xxxxx] issued to 'computername.domain' doesn't have private key or caller doesn't have access to private key. 3/18/2016 11:12:11 AM 8816 (0x2270) Completed validation of Certificate [Thumbprint xxxxx] issued to 'computername.domain' 3/18/2016 11:12:11 AM 8816 (0x2270) GetSSLCertificateContext failed with error 0x87d00283 3/18/2016 11:12:11 AM 8816 (0x2270) GetHttpRequestObjects failed for verb: 'GET', url: 'https://configmgr.domain/CCM_Client/ccmsetup.cab' 3/18/2016 11:12:11 AM 8816 (0x2270) DownloadFileByWinHTTP failed with error 0x87d00283 3/18/2016 11:12:11 AM 8816 (0x2270) CcmSetup failed with error code 0x87d00283 3/18/2016 11:12:11 AM 10828 (0x2A4C) I am able to browse to the https port on the configmgr server (2012R2). Any thoughts where to begin troubleshooting? Clients are both windows 7 and 10. Thanks

I went ahead and ran the powershell script to enable the faster availability of the update then restarted the SMS_DMP_Downloader service and the update began to download. Everything appeared to go just great (no errors) but then at the end of the process the logs show: WARNING: Failed to obtain easy setup payload. Retry in the next polling cycle. Rebooted and the update tried to download again and failed. Thoughts? ---Update: Even though I have the error in the log, I did get the notification in the Console that an update is available and it now shows up to where i can install it. So maybe all is ok?

Hello, So I have 6 devices without clients in the default "All Desktop and Server Clients" Collection. If I run the query the collection is based on, I only get the machines with client installed. (I've removed the computers w/clients from the screenshot) Seems pretty hard to mess this collection up. Wondering if anyone has noticed this or if its another bug? Thanks

Also will mention that I noticed none of our Windows 10 packages appear to be running even though they are deployed. Further checking revealed a large majority of the packages were set to disabled rather than enabled. I'm unable to duplicate the issue so not sure if its a bug or just something odd on our end. MS was unable to duplicate the issue as well but said there were a lot of bugs in regards to migration in the current version which will hopefully be fixed in the next CU. Just a heads up in case anyone ran into something similar.

Yep, got the confirmation from Microsoft as well. This affects not only packages, but also Task Sequences. No fix as of yet so hopefully will be in the next update/version for Configmgr.

Hello, I was able to duplicate it twice. Imaged attached. So looks like a bug? Whats the easiest way to report? Same method as opening a support case?

OK so made it through all the packages (65) and none of them retained this previous setting.

Hello, Just happened to notice that on all my 2012R2 packages, the "Requirements" tab on the Program seems to have not migrated the "All Windows 10 (64-bit)" setting. (I guess I can't say all but I'm through the 1st 10 packages and none of them have this checked as is on the source package. Anyone else notice this or is this a known bug?

So for the time being the GPO's are handling the site assignments so what is published in AD does not matter as long as we have the GPO's in place. Correct?

Hello, We are moving from 2012R2 to CB and I'd like to verify the following in regards to migrating the clients over to the new system. We have 2 boundary groups configured for the geographical location of the clients which may cause a problem as the groups will overlap and there isn't really a way so segregate them out. The old system is published in AD and the new one is not. The biggest divide in our clients regarding migration are workstations and servers. We plan to do workstations first, then servers. Currently both wks and server OU's have GPO's configured for install and site assignments. We have the following GPO's configured on our wks and server OU's -Configure ConfigMgr 2012 Client Deloyment Settings (ccmsetup.exe install parameters to r2 site) -Configure ConfigMgr 2012 Site Assignment = r2 site -Specify intranet MS update service location = r2 sites WSUS I will assume this takes precedence over what is published in AD so if that is correct, publishing the new site so both are listed in AD will not cause a problem? When we go to migrate our clients, we can change the GPO settings on the respective OU's to:: -Configure ConfigMgr 2012 Client Deloyment Settings (ccmsetup.exe install parameters to cb site) -Configure ConfigMgr 2012 Site Assignment = cb site -Specify intranet MS update service location = cb sites WSUS and let the clients grab the new sccm client from WSUS (where it is published) and it will upgrade and move over to the new system. Once we have all the clients migrated, unpublish the r2 site from AD and modify the GPO's as follows: Configure ConfigMgr 2012 Client Deloyment Settings = remove Configure ConfigMgr 2012 Site Assignment = remove Specify intranet MS update service location = cb sites WSUS any new installs going forward will just grab the install information from AD. Does this seem logical?

Update: Looks like things may be going over HTTPS rather than HTTP after all. When I was looking at the Location Services.log it would reference the DP with http rather than https. Since our environment (except for fsp) is https, i expected to see https there. However, I blocked http traffic to and from the DP on this host and was able to install a package located on 1 DP that installed correctly and then 1 from the DP in question. I checked the DataTransferService.log and its showing the transfer using https. So my question is, as things look like they are working correctly, is there anything else that should be checked to ensure nothing is missing on this DP's config to prevent an unknown issue from popping up in the future? Thanks

Hello, Running into an issue with a newly deployed DP. It seems when the role is installed, its not adding the SSL bindings in IIS. I found one other report of this (https://social.technet.microsoft.com/Forums/en-US/ccea8475-09b4-4d59-8cbd-11e8e41debe7/distribution-point-site-role-not-creating-ssl-site-binding-in-iis?forum=configmanagergeneral). Unfortunately it looks like for this person some registry entries and adding the https binding fixed the issue. I'm not sure what regedits might be missing, but I did manually add the binding and my IIS cert and I'm able to view the default IIS page over https. If i try to run a package from that DP it works; however, its going over HTTP rather than HTTPS, so something appears to be missing. I'd prefer not to manually add/hack things because if it didn't install correctly by itself, who knows what might be broke. I've already removed the role and and site system, reboot the target machine then re-install the roles and no change. The DP is configured to use HTTPS and a DP PKI cert has been imported as well. Any thoughts how to get this installed correctly? The only abnormal thing I can think of that I did was that I installed IIS (and the normal site system/distribution point) roles and features before installing the site system and distribution point. Looks like that's not required since the install and configuration of IIS is an option in the wizard. I'd guess if I was missing something regarding the IIS config that when the add roles wizard ran it would have fixed any mistakes (which I don't believe I did since the install logs look ok). OS= 2012R2 Thoughts?