Today my vacation is starting for the next coming weeks. During my vacation there will be no new blogposts as you can guess :) So enjoy yourself (I will do also) and expect a lot of new information and knowledge later this year. There will be lot to write and share about upcoming and already available Microsoft products:
-Windows 10 AE
-System Center 2016
-Microsoft Intune & Azure
-Enterprise Mobility Suite
-Windows Server 2016
-Windows 10 Mobile
I hope to attend the following events too:
-Microsoft Ignite (September 26-30)
-Experts Live (November 22th)
Thanks for visiting my blog and see you later!
 |
| It's vacation time now! |
It was known already that both System Center 2016 and Windows Server 2016 were released in Q3 this year. On several blogposts now it's mentioned that both solutions will be launched at the Microsoft Ignite conference in late September. Let's have a look at some highlights of both solutions:
System Center 2016 aims to ease the deployment, configuration, management and monitoring of your virtualized, software-defined datacenter and hybrid cloud infrastructure built on Windows Server 2016. A key goal of System Center 2016 is to improve the performance and the usability of System Center components to enhance your operational experience.
Highlights of System Center 2016 include:
-Support for new Windows Server 2016 technologies, including lifecycle management for Nano server-based hosts and virtual machines, Storage Spaces Direct, and shielded virtual machines;
-Performance and usability improvements, including all the update rollups since System Center 2012 R2, improved UNIX and Linux monitoring, and ability to tune management packs and alerts;
-Native integrations with Microsoft Operations Management Suite to give you expanded analytics, data correlation, orchestration, archival, and hybrid management capabilities.
Windows Server 2016 is the cloud-ready operating system that delivers new layers of security and Azure-inspired innovation for the applications and infrastructure that power your business.
Highlights of Windows Server 2016 include:
-Increase security and reduce business risk with multiple layers of protection built into the operating system.
-Evolve your datacenter to save money and gain flexibility with software-defined datacenter technologies inspired by Microsoft Azure.
-Innovate faster with an application platform optimized for the applications you run today, as well as the cloud-native apps of tomorrow.
Just great to have new functionality coming soon!
Used sources:
System Center 2016 to launch in September
What’s new in System Center 2016 Technical Preview 5
Windows Server 2016 new Current Branch for Business servicing option
Last week (July 22th) the following ConfigMgr version is released: Update 1606 for ConfigMgr Current Branch. With this update new update functionality in ConfigMgr Current Branch can be used finally. No need to install servicepacks or cumulative updates anymore. Just make sure there's a recent back-up and install this version.
This update includes the following improvements:
-Windows Information Protection (formerly EDP)
-Windows Defender Advanced Threat Protection
-Windows Store for Business Integration
-Windows Hello for Business
We’ve also added a number of popular User Voice items, including:
-The addition of content status links in the admin console
-The option of list view for applications in the Software Center
-The ability to select multiple updates and simultaneously install them with the new Install Selected Updates button in the Software Center
For more details and to view the full list of new features in this update check out our documentation on TechNet.
Just great a new version is available now!
Source: ConfigMgr Team Blog
In an earlier blogpost I explained Azure RemoteApp (ARA) functionality and to publish native and virtual (App-V) applications. Now the story continues with some other device experiences. Therefore I installed the Remote Desktop client on a Windows 10 Mobile, Android phone and iPad 3 device. Let's have a look again.
ARA can be used on a variety off devices. Sounds like a cool scenario to use Windows applications on multiple devices.
On a Windows 10 Mobile you need to install Remote Desktop client and logon. As easy as that. All applications published can be started within a RDP session.
On iOS (iPad) you need to install Remote Desktop client and logon. As easy as that. All applications published can be started within a RDP session.
Besides of the Azure RemoteApp RDP client and Windows 10 Remote Desktop client, you can use the Windows Azure RemoteApp website as well. That's the third option I found to access published applications.
Hope there will be still some development on ARA policies (you won't want to use "Save as" on the RDS host within applications), publish specific applications to users and/or groups, and ugly logon screen during logon.
Hope you like my posts so far on ARA functionality!
Check earlier blogposts:
Azure RemoteApp Part 1 and Part 2
In an earlier blogpost I explained Azure RemoteApp (ARA) functionality and to setup a virtual machine. Now the story continues with a new ARA collection, build on the virtual machine template created earlier. After that applications are published to make them available.
Steps to take:
Create a new ARA collection. You can choose between:
-Cloud based: Create and manage RemoteApp collections running in Windows Azure.
-Hybrid based: Create a hybrid deployment of RemoteApp that uses VNet to connect to your on-premise infrastructure.
The virtual machine template created earlier must be available now.
Choose the new template created and continue. As you can see it's not that hard to create a new collection. This will take even more time now, so be patience again ;)
When done choose "Configure user access" and "Publish RemoteApp programs" to make them available to end users.
Both native and virtual (App-V) applications will be published now. Just select the ones to publish to end users.
Once the applications have been published and user access has been configured, you can then download the Azure RemoteApp RDP client (or use the Windows 10 Remote Desktop client instead).
After you have been authenticated, you will see your published applications (both native and virtual applications) assigned and published to the user. You can then begin to test virtual application behavior in Azure RemoteApp.
They will be added to the local start menu automatically, which is very cool if you ask me :-) Applications are integrated seamless, where you cannot seen if they are installed locally, or added by ARA. No locally installed App-V client is needed as well.
Check the Roadmap too:
-What's coming in Azure RemoteApp
And remember: with added value like the "Ability to publish individual applications to specific users" it will be even better :-)
For a customer environment it was needed to offer applications to local devices, without using a local infrastructure. Because Microsoft Cloud is the way to go, I was thinking about Azure RemoteApp (ARA). Let's have a look at the solution and how to implement it for offering applications. It is not that hard to setup.
ARA helps employees stay productive anywhere, and on a variety of devices (Windows, Mac OS X, iOS, or Android). Your company’s applications run on Windows Server in the Azure cloud, where they’re easier to scale and update. Employees simply install Remote Desktop clients on their (Internet-connected) PC, Mac, tablet, or phone and then access applications as if they were running locally. Sounds easy isn't it?
Pro's and cons:
-ARA is available in the old Azure portal only (for now). It will be available in the new Azure portal later this year.
-Applications within a single collection can be offered to specific users or groups only. Not possible to divide them to different users or groups. This will be available in the new Azure portal later.
-Deploying virtual (App-V) applications within ARA isn't supported by Microsoft. It is working, but not a recommended option. This will be supported in future in the new Azure portal.
-Deploying virtual (App-V) applications within ARA is supported in hybrid collections only. When using cloud collections this isn't the case. It is working, but not a recommended option.
Steps to take:
-Open the Azure portal, go to virtual machines and create a new "Windows Server Remote Desktop Session Host" from template. Choose the configuration wanted and wait for it to complete.
-The applications needed can be installed native or may be virtual (App-V) as well. Make sure the App-V Client for Remote Desktop Services is installed too, when App-V packages are used.
-To register App-V packages for later usage, use the following command(s): Microsoft TechNet. Don't start them yet, otherwise delete data in the local VFS Folder (%LOCALAPPDATA%\Microsoft\AppV\Client\VFS) for sure.
When ready start ValidateRemoteAppImage.ps1 on the desktop. This script will check for errors and start Sysprep afterwards. The virtual machine will be stopped afterwards.
Choose to capture the virtual machine afterwards (Capture button).
Go to RemoteApp now and "Add a new template image". The virtual machine captured before must be available now. This will take some time, so be patience ;)
That's it for now. In a next blogpost I will continue creating a new ARA collection, and publish some applications.
Check weblinks:
-Using App-V apps in Azure RemoteApp
-Create a Azure RemoteApp image based on an Azure virtual machine
-Capture an image of an Azure Windows virtual machine created with the classic deployment model
-App-V: On App-V Applications Hosted in Azure RemoteApp
Update 14-7: Change on virtual (App-V) applications. Thanks to @ArjanVroege and @fberson for comments.
Last month (June 2016) I went to both Windows Management User Group (WMUG) and System Center User Group (SCUG). Both with great sessions and speakers. On WMUG both Mirko Colemberg and Mike Terrill were speaking. On SCUG I listen to Pieter Wigleven, Stefan van der Wiele, Mirko Colemberg and Peter Daalmans. Let's have a look at some notes taken.
SCUG #1 (Pieter Wigleven)
-Windows 10 enrollment options: Join devices to Azure AD, Password reset, Require multi-factor, Sync settings, Application proxy
-Apps like Twitter (for example) can be installed automatically
-Windows Information Protection policies within Intune standalone (AKA Enterprise Data Protection)
-Edition upgrade policy Pro > Enterprise (or the other way around) with a provisioning package
-Wi-Fi profile and Defender block (within Intune policy)
-Use myapps.microsoft.com (access panel) for additional apps (with SSO support)
-Deploy Line-Of-Business (LOB) apps via Microsoft Business store
-Add x86 software to Microsoft Business store (future usage)
-When using BitLocker encryption policies, the recovery password will be kept in Azure too.
-No Direct Access support in Azure till now, but Auto-VPN instead.
SCUG #2 (Mirko Colemberg)
-Session on Microsoft Advanced Threat Analytics (ATA) and Windows Defender Advanced Threat Protection (ATP)
-Story (ATA): 200+ days. That's the average amount of time that attackers reside within your network until they are detected, gathering classified data and information, waiting to strike at just the right moment. Microsoft ATA helps you identify breaches and threats using behavioral analysis and provides a clear, actionable report on a simple attack timeline.
-Story (ATP): Protecting our enterprise customers has never been more challenging. Security threats are increasingly brazen and highly sophisticated. A new Windows 10 service that helps our customers to detect, investigate and respond to targeted and advanced attacks on their network.
-Source: Microsoft ATA & Microsoft ATP
-Microsoft ATA is only for information, not for protection. Maybe it will be combined with Defender in future.
-Windows Defender ATP policies will be in SCCM (next build), but is not in Intune available at the moment.
SCUG #3 (Peter Daalmans)
-Start with ConfigMgr 1511 during clean install or upgrade. Don't use build 1602 for this. Possible but not recommended!
-Since ConfigMgr Technical Preview (1511) there was an update every month (with new features)! Very good job Microsoft.
-New ConfigMgr Current Branch builds needs to be installed within a year, to be supported. No LTSB version available.
-Use the service connection tool for new ConfigMgr builds, when in offline mode or behind a proxy. Cool stuff! > Microsoft
-After 1602 it's not possible to upgrade or install newer builds directly. It will break ConfigMgr and missing features!
More on Servicing here: Promote the ConfigMgr client in Current Branch (1602)
More about WMUG and SCUG sessions HERE.
Another post on the error message "Remote configuration failed on WSUS Server" with ConfigMgr and WSUS. This time the error message came back multiple times, so software updates cannot be synchronized anymore. Both solution mentioned on my other blogposts weren't working here:
-
Remote configuration failed on WSUS Server (part 1)
-
Remote configuration failed on WSUS Server (part 2)
When looking in Site and System status the following is seen: WSUS Synchronization failed. Message: WSUS server not configured. Please refer to WCM.log for configuration error details..
When looking in WCM.log: Remote configuration failed on WSUS Server.
When looking in wsyncmgr.log: Sync failed. Will retry in 60 minutes
The solution for this is not that hard. Open WSUS console first. You will see that WSUS isn't working at the moment. "Reset Server Node" isn't helping here.
Open Server Manager > IIS Manager > Application Pools. You will see that Wsuspool is stopped. Starting the pool will solve the issue temporary. Don't start it yet, but configure it first!
Just open Advanced settings on Wsuspool instead, and change the memory value there. This is needed to make sure the same error will not come back after a few days.
Change the Private Memory Limit to 4GB (4000000 KB). The default value is 1843200 KB here. After that Application Pool must be started manually. When things are okay now, WSUS is working again.
Happy with this easy solution!
Source: Microsoft
Last month (June 2016) I went to both Windows Management User Group (WMUG) and System Center User Group (SCUG). Both with great sessions and speakers. On WMUG both Mirko Colemberg and Mike Terrill were speaking. On SCUG I listen to Pieter Wigleven, Stefan van der Wiele, Mirko Colemberg and Peter Daalmans. Let's have a look at some notes taken.
WMUG #1 (Mirko Colemberg)
-Integrate Windows Store for Business (WSfB) in ConfigMgr 1605TP or 1606 directly. Just advertise them within ConfigMgr directly.
-Assign to users or user groups? Also for user groups! (WSfB)
-Wsreset.exe = reset the store (when it's malfunction)
-You can drawback apps too! Then the user cannot open the app anymore.
-Block Windows 10 Public Store using Microsoft Intune (but still allow the business store) > Microsoft
-Integration in MS Intune available, all apps are visible there too! Just advertise them within MS Intune directly.
-Use developer.microsoft.com for creating LOB apps yourself.
-Some Windows 10 apps are for Mobile usage only, others for Desktops usage.
-Apps can be used online and (sometimes) offline. It depends..
-Use PowerShell for adding APPX packages, not the CM or Intune wizard.
More on WSfB here: Using the new Windows Store for Business for apps on Windows devices
WMUG #2 (Mike Terrill)
-Using Resource Explorer to watch BIOS and UEFI information on Dell, HP and Lenovo systems.
-For Windows 10 Redstone you need ConfigMgr Current Branch, not 2012 (R2) anymore (because not supported)
-Using 1507 (RTM) or 1511 boot images? Hotfix needed for 1511, so better use the 1507 bits.
-Upgrade BIOS versions during task sequence possible! Need to test this myself first, and report later.
-Download package content > task sequence working directory (for reference packages)
-Dell systems: Use Dell Client Configuration Utility > Download
-HP systems: Use HP BIOS Configuration Utility > Download
-Lenovo systems: Use BIOS Deployment Guide > Download
-New dynamic variables available within ConfigMgr builds
-Using 1E’s Free Tools > Download
More on UEFI here: Choosing between BIOS (Legacy) or UEFI during deployment
Stay tuned for more information in a next blogpost!
Within a ConfigMgr Current Branch environment with multiple untrusted forests, the following error message was seen in Site and System status: Active Directory System Discovery Agent failed to bind to container LDAP. This on every 5 minutes (delta discovery).
-Error: The specified domain either does not exist or could not be contacted.
-Possible cause: The AD container specified earlier might be invalid now. The Domain Controller is inaccessible.
-Solution: Please verify that the AD container paths specified are valid. Confirm accessibility of the site server to the Domain Controller to be queried.
Looking in adsysdis.log error 0x8007054B is given:
-ERROR: Failed to bind to LDAP://OU=Test,DC=Contoso,DC=local (0x8007054B)
-ERROR: Failed to enumerate directory objects in AD container LDAP://OU=Test,DC=Contoso,DC=local
When looking in Active Directory System Discovery the following was configured: LDAP://OU=Test,DC=Contoso,DC=local (for example)
This for every untrusted forest given..
When looking in sitecomp.log however the following was seen:
-Processing forest contoso.local.
-Publishing account user account <Domain>\<Account> will be used
-DS Root:DC=Contoso,DC=local
-Searching for the System Management Container.
-LDAP://Contoso.local/CN=System Management,CN=System,DC=Contoso,DC=local container exists.
So yes, there must be an extra FQDN step in between.
Just change LDAP://OU=Test,DC=Contoso,DC=local to LDAP://Contoso.local/OU=Test,DC=Contoso,DC=local for every untrusted forest in Active Directory System Discovery and you will be fine. (for example)
Looking in adsysdis.log again will show the following information:
-INFO: Bound to LDAP://Contoso.local/OU=Test,DC=Contoso,DC=local
-INFO: successfully completed directory search
-INFO: Start to recursively process into group objects
-INFO: Finished recursively processing into group objects
So no errors in adsysdis.log and Site and System status seen anymore. Very happy with the solution!
Source: Anoop C Nair
Recently it was needed to install ConfigMgr Current Branch (1602) in an environment with multiple forests with a single domain each. Most of times I install ConfigMgr in a single forest, where one or multiple domains resides or multiple forests with a trust in between. This time it was needed to publish site information across multiple forests without any trusts. Let's have a look at the steps taken.
First you need to configure conditional forwarders from the forest where ConfigMgr is installed to all remote forests where site systems are needed. Otherwise no forest discovery is possible at all.
After that the following must be done:
-Add a forest in ConfigMgr with a domain account from the remote forest. This account must have read permissions on the root of the forest at minimum.
-Run a schema update on the remote forest (schema master) manually by copying the files needed.
-Create a System Management container on the remote forest (without additional permissions needed)
-Create a boundary and boundary group for the remote forest (may be created by forest discovery automatically)
-Create a Network Access (NA) account on the remote forest and configure it in the ConfigMgr console
-Create a Push Installation (PI) account on the remote forest and configure it in the ConfigMgr console
-Run system discovery on the remote forest (with the remote NA account), where LDAP locations must be configured manually
-Set publishing in Site properties on the remote forest
After that forest discovery and publishing must be succeeded. When installing remote site systems, make sure the account for the remote forest is used now. This because the ConfigMgr computer account cannot be used in this case. Hope it helps!
Today (June 21th) the latest ConfigMgr (preview) version is released: Update 1606 for ConfigMgr Technical Preview. Update 1606 for Technical Preview is available directly in the ConfigMgr console. If you want to install ConfigMgr Technical Preview for the first time, the installation bits (currently based on Technical Preview 1603) are available on TechNet Evaluation Center.
This update includes the following improvements:
-ConfigMgr as a managed installer with Device Guard (ConfigMgr-deployed software is automatically trusted)
-Cloud Proxy Service (manage ConfigMgr clients on the Internet, with an Azure subscription)
-Grace period for application and software update deployments (give users a grace period to install required applications or software updates)
-Multiple device management points for Windows 10 Anniversary Edition devices (automatically configures an enrolled device to have more than one device management point available for use)
This update also includes new features for customers using ConfigMgr integrated with Intune (hybrid scenario):
-Device categories (automatically place devices in device collections when used in hybrid environments)
Hope that nested task sequences will be available soon too!
Just great a new (preview) version is available now!
Source: Enterprise Mobility and Security Blog
Recently I did some blogposts about ConfigMgr issues and improvements, which I posted on Microsoft Connect.
More about that here:
Issue in ConfigMgr Current Branch (1602) with Intune subscription Some small bugs found in ConfigMgr Current Branch (1602)
The current status after two months looks good to me:
-Issue in ConfigMgr Current Branch (1602) with Intune subscription (when changing tentant) = Fixed
-Order in ConfigMgr and SCEP policies not corrected after removing other policies = By design
-Remote configuration failed on WSUS Server, after ConfigMgr Current Branch upgrade = Active
-The SMS Provider reported an error, Quota violation, when drivers are movged to a different folder = Fixed
-To enable use the Add Site System Roles wizard to add the Intune Connector role = Fixed
-This device might have Activation Lock enabled and might require the user's Apple id and password to be entered to be reactivated = Won't fix
-Default layout for deployment status of task sequences (Monitoring part) = Active
-To identify the Windows Store link for this application, browse to a computer that has the application installed = Active
As for the "Order in ConfigMgr and SCEP policies not corrected after removing other policies" the following details:
This is actually changed by design in ConfigMgr v1511. Several customers asked for the ability to configure security scopes for antimalware policies; there are some existing Connect items for it (e.g. 1015855 and 1015641).
The reason we made this change is because a ConfigMgr admin who is subject to security scopes cannot always "see" the policies of other users. If they change the priorities of their own policies, when the Console cannot "see" the other admins' policies, then it is possible to end up with two policies having the same priority. If both of these policies are present on a client, then the client cannot reconcile the two policies and may encounter errors.
We altered the priority logic to guarantee that no two have the same priority, even when there are scoped users involved. As a result of this we no longer reshuffle priorities when policies get deleted.
Very good to see that Microsoft is still making progress here, with most issues fixed and a few active! Way to go :-)
Recently (May 27, 2016) for ConfigMgr Current Branch (1602) is released, also known as KB3155482. It fixes multiple issues on both ConfigMgr and Microsoft Intune. It cannot be downloaded, but will be available in the ConfigMgr console instead.
Here's a list of issues that are fixed:
-Remote Control (1x)
-Site Systems (1x)
-Microsoft Intune and mobile device management (5x)
As you can see it fixes mostly Intune (MDM) parts. When not using Intune, just wait for build 1606 coming soon.
This hotfix is available for installation in the Updates and Servicing node of the ConfigMgr console. If the service connection point is in offline mode, you have to re-import the update so that it is listed in the ConfigMgr console.
For more information on the update have a look here:
Microsoft Support
Hopefully the ConfigMgr certificate issue is solved now too!
Last year we began moving Intune Account Portal functionality to the Office 365 management portal. This move is now complete (May 26, 2016) and the Intune Account Portal has been retired.
Users and Groups are managed in appropriately named tabs whereas purchasing and subscription management is now under Billing.
Depending on how you purchased, you will access software downloads at either the Volume Licensing portal or the Microsoft Online Services Customer Portal.
Be sure to update your bookmarks.
Read more about the move in our Microsoft Intune blog or go directly to the new Office 365 management portal with your existing credentials.
Source: Microsoft Blogs
Within ConfigMgr Current Branch (1602) the production client isn't updated by default anymore. After installation (and/or upgrade) both a ConfigMgr Client Package and ConfigMgr Client Piloting Package are created. This is different in earlier versions, where the production client was upgraded immediately. Benefit of this is to test the client first, before enroll it to all company devices.
Both a ConfigMgr Manager Client Package and ConfigMgr Manager Client Piloting Package are available now.
During upgrade a pre-production collection must be created. Just add a few systems in it for testing purpose, and you will be fine.
Within a deployment task sequence this can be tested to. Just deploy a system with the new pre-production client, and check if it's installing fine. Just choose "Use pre-production client package when available" and browse to the ConfigMgr Client Piloting Package.
When successful go to Cloud Services > Updates and Servicing > and check Client Update options. Check "I am ready to make pre-production client version available to production" to update the Configuration Manager Client Package. The ccmsetup.exe in the ConfigMgr client folder will be upgraded now. Yeah!
Just great to have more control on the client version now!
With Windows 10 in enterprises, it's recommended to devide systems between Current Branch (CB) and Current Branch for Business (CCB). Where few systems will be in CB for testing new functionalities, most systems will be in CBB probably. Difference is a 4 months delay for new Windows 10 builds, which can be extended for another 8 months to have a 12 months delay in total. After 1 year you're out of support, and no security updates will be offered anymore.
To divide systems between CB and CBB, Group Policy and/or ConfigMgr can be used. Within the new group policy templates, the following settings is available: Defer Upgrades and Updates
When this policy is enabled and linked, a 4 months delay is the result. This can be extended for another 8 months on upgrades and 4 weeks on updates. You can pause upgrades and updates too. Nothing wrong with that.
When using ConfigMgr Current Branch things get a bit different. Now you have a Windows 10 Servicing dashboard and CB is called Release Ready (RR). CBB is called Business Ready (BR) here. Why using different terms here is not handy and not logical to me. It's also not easy to move systems from RR to BR. Therefore lot's of prerequisites must be in place.
When looking on: Manage Windows as a service using System Center Configuration Manager you will see the prerequisites:
- Windows 10 computers must use ConfigMgr software updates with WSUS for software update management
- WSUS 4.0 with KB3095113 must be installed on your software update points and site servers
-Enable Heartbeat Discovery (7 days by default)
-The service connection point must be installed and configured for Online, persistent connection mode to see data on the Windows 10 servicing dashboard
-Specify the group policy setting, Defer Upgrades and Updates, to determine whether a computer is CB or CBB
-IE9 or later must be installed on the computer that runs the Configuration Manager console
-Software updates must be configured and synchronized
Strange thing is however, you need to configure group policy and a servicing plan too. Here you can choose between CB or CBB and there's a delay of 120 days possible. This is around 4 months, and not the same as the 8 months which can be configured in group policy. Why the difference here, on days instead of months?
On Manage Windows as a service using System Center Configuration Manager you will see the following on that: "How many days after Microsoft has published a new upgrade would you like to wait before deploying in your environment". Maybe I want to wait 12 months, how to configure that? Hope that someone or Microsoft can clarify something on that.
For now I see most environments with systems in CB/RR without the possibility to move them to CBB/BR easily.
Request: Besides of that I want to click on the dashboard, to see which systems has which build installed and which ring is configured. That will has benefit above off the value displayed.
Will be continued..
During a new Windows 7 SP1 installation, it went stuck on checking for updates. I did see Windows update issues a lot last years on Windows 7 SP1. This one is really nasty, because it stays on "Checking for updates" for hours.. Not that cool if you ask me.
The solution is really easy. Just download KB3102810 (Installing and searching for updates is slow and high CPU usage occurs in Windows 7) here and install it on the client. Better stop the Windows Update service first, to speed up the installation process.
Another solution is to download both KB3138612 (Windows Update Client for Windows 7: March 2016) and KB947821 (System Update Readiness Tool) and install them on the client. Better stop the Windows Update service again as mentioned before.
When still having issues, you can try Microsoft Easy Fix also! Hope it helps for you too :)
Source: superuser
In the meanwhile the following solution is available too:
Simplifying updates for Windows 7 and 8.1
It mentions: We’re happy to announce that we’re making available a new convenience rollup for Windows 7 SP1 that will help. This convenience rollup package, available to download from HERE, contains all the security and non-security fixes released since the release of Windows 7 SP1 that are suitable for general distribution, up through April 2016. Install this one update, and then you only need new updates released after April 2016.
Other blogposts on Windows update:
Some clients not updating, reporting 8007000E error
Software Update Error 0x80004005 on client systems
Recently I did some blogposts about the difference using Intune Standalone or ConfigMgr hybrid mode.
You can find them here: part 1 / part 2 / part 3
For ConfigMgr hybrid mode I mentioned the following:
As for ConfigMgr hybrid mode, this must be done in Configuration items and baselines, where not sure when they arrive. Monitoring - deployments is not the right place also, given a 'Unknown' status most of times. Did a lot of compliance checks and reboots on mobile devices, but nothing seems to happen..
Trick is, you need to do some additional configuration. When policies in Intune are working immediately, they are in ConfigMgr not.
When creating configuration items in ConfigMgr, "Remediate noncompliant settings" is turned on by default.
When creating and deploying configuration baselines, this is not the case. "Remediate noncompliant rules when supported" is not turned on by default. Trick is, you need to enable this for making them active.
In the baseline deployment properties "Remediate noncompliant rules when supported" must be selected. I did change the schedule for 7 days to 5 minutes too. After that configuration was starting on mobile devices right away.
Why this isn't configured by default is the question? Without this setting you can wait forever for policies to come through..
Almost 3 years ago I did a blogpost on deploying printer drivers during a task sequence. That one is based on PnPutil.exe which is fine, but probably not the best solution. Therefore using a CMD file, with multiple commands for different printer models may be better. Let's have a look at that.
When you want to deploy a single print driver or multiple printer drivers, use the following command instead:
RUNDLL32 PRINTUI.DLL,PrintUIEntry /ia /m "<Printer model>" /f "<INF path>\<INF filename>"
RUNDLL32 PRINTUI.DLL,PrintUIEntry /ia /m "<Printer model>" /f "<INF path>\<INF filename>"
RUNDLL32 PRINTUI.DLL,PrintUIEntry /ia /m "<Printer model>" /f "<INF path>\<INF filename>"
This command can be placed multiple times in a CMD file (for example), so just create folders for different models and drivers, and have a CMD file in the root, which is pointing to the different locations. That way printer drivers can be installed easily.
Hope it helps!
