by Mark | Mar 9, 2016 | Patch Releases, Security
The following thirteen Patch Tuesday updates / patches have been released by Microsoft for the January 2016 Update deployment.
Are you ready to start deploying and remove the patching risk using SnaPatch Patch Management Software?
MS16-023 – Critical
Cumulative Security Update for Internet Explorer (3142015)
This security update resolves vulnerabilities in Internet Explorer. The most severe of the vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Internet Explorer. An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.
MS16-024 – Critical
Cumulative Security Update for Microsoft Edge (3142019)
This security update resolves vulnerabilities in Microsoft Edge. The most severe of the vulnerabilities could allow remote code execution if a user views a specially crafted webpage using Microsoft Edge. An attacker who successfully exploited the vulnerabilities could gain the same user rights as the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
MS16-025 – Important
Security Update for Windows Library Loading to Address Remote Code Execution (3140709)
This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow remote code execution if Microsoft Windows fails to properly validate input before loading certain libraries. However, an attacker must first gain access to the local system with the ability to execute a malicious application.
MS16-026 – Critical
Security Update for Graphic Fonts to Address Remote Code Execution (3143148)
This security update resolves vulnerabilities in Microsoft Windows. The more severe of the vulnerabilities could allow remote code execution if an attacker either convinces a user to open a specially crafted document, or to visit a webpage that contains specially crafted embedded OpenType fonts.
MS16-027 – Critical
Security Update for Windows Media to Address Remote Code Execution (3143146)
This security update resolves vulnerabilities in Microsoft Windows. The vulnerabilities could allow remote code execution if a user opens specially crafted media content that is hosted on a website.
MS16-028 – Critical
Security Update for Microsoft Windows PDF Library to Address Remote Code Execution (3143081)
This security update resolves vulnerabilities in Microsoft Windows. The vulnerabilities could allow remote code execution if a user opens a specially crafted .pdf file.
MS16-029 – Important
Security Update for Microsoft Office to Address Remote Code Execution (3141806)
This security update resolves vulnerabilities in Microsoft Office. The most severe of the vulnerabilities could allow remote code execution if a user opens a specially crafted Microsoft Office file. An attacker who successfully exploited the vulnerabilities could run arbitrary code in the context of the current user. Customers whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.
MS16-030 – Important
Security Update for Windows OLE to Address Remote Code Execution (3143136)
This security update resolves vulnerabilities in Microsoft Windows. The vulnerabilities could allow remote code execution if Windows OLE fails to properly validate user input. An attacker could exploit the vulnerabilities to execute malicious code. However, an attacker must first convince a user to open either a specially crafted file or a program from either a webpage or an email message.
MS16-031 – Important
Security Update for Microsoft Windows to Address Elevation of Privilege (3140410)
This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker is able to log on to a target system and run a specially crafted application.
MS16-032 – Important
Security Update for Secondary Logon to Address Elevation of Privilege (3143141)
This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if the Windows Secondary Logon Service fails to properly manage request handles in memory.
MS16-033 – Important
Security Update for Windows USB Mass Storage Class Driver to Address Elevation of Privilege (3143142)
This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker with physical access inserts a specially crafted USB device into the system.
MS16-034 – Important
Security Update for Windows Kernel-Mode Drivers to Address Elevation of Privilege (3143145)
This security update resolves vulnerabilities in Microsoft Windows. The vulnerabilities could allow elevation of privilege if an attacker logs on to the system and runs a specially crafted application.
MS16-035 – Important
Security Update for .NET Framework to Address Security Feature Bypass (3141780)
This security update resolves a vulnerability in the Microsoft .NET Framework. The security feature bypass exists in a .NET Framework component that does not properly validate certain elements of a signed XML document.
by Mark | Mar 7, 2016 | SCCM
System Centre Configuration Manager (SCCM) Auto Deployment Rule Error 0x87d20415
Are you experiencing Auto Deployment Rule Error 0x87d20415 in SCCM? Don’t worry, it’s a common issue related to SCCM’s hard-coded limit on the number of updates that can be downloaded by an Automatic Deployment Rule. To fix it, check your Auto Deployment Rules in SCCM’s Software Library and investigate the issue by examining the ruleengine.log file. Once you’ve identified the problem, set the Date Revised or Released to the last month, go to your Automatic Deployment Rule, and choose Run Now. After completing this process, check the ruleengine.log file again to ensure that updates download without any issues. By following these steps, you can easily overcome Auto Deployment Rule Error 0x87d20415 in SCCM and ensure that your Automatic Deployment Rules run smoothly. For more helpful solutions to SCCM deployment issues, be sure to check out our other articles.
Check your Auto Deployment Rules
When you notice that updates haven’t been downloading as intended, one of the first things to check is your Auto Deployment Rules. Go to the Software Library in SCCM and select Automatic Deployment Rules. In the main window, you should be able to see the error code and why your Auto Deployment Rule hasn’t run. The error in this case is 0x87d20415.
Go to Software Library and choose Automatic Deployment Rules
I
In the main window you should be able to see the error code and why your Auto Deployment Rule hasnt run. The error in this example is 0x87d20415, as per the below image.
The issue is that SCCM has a hard coded limit on the number of updates (1000) that can be downloaded by an Automatic Deployment Rule. The best place to start to investigate that this is the case, is to check the ruleengine.log, located install directory – Microsoft Configuration Manager – Logs – ruleengine.log.
Looking at the file with cmtrace, you should be able to easily identify that this is in fact the issue. (Issue highlighted in yellow)
You can see that the ADR has hit the 1000 update limits as highlighted in yellow above.
To overcome this issue, you need to set the date revised or released to the last month. This way, SCCM will only check for updates released in this period. To do this, right click on your Automatic Deployment Rule and click properties. Go to the Software Updates tab, and choose Date Released or Revised, and set this for a more suitable time frame (1 month should suffice, but this does depend on your Update deployment schedule)
Once you have changed this range, go to your Automatic Deployment Rule, and choose Run Now.
Once this has been completed, check the Ruleengine.log once again, and you should hopefully see that the updates are now in fact downloading and the dreaded error, Auto Deployment Rule Error 0x87d20415 has disappeared.
In conclusion, fixing Auto Deployment Rule Error 0x87d20415 in SCCM can be quite simple. By following the steps outlined above, you can resolve this issue and ensure that your Automatic Deployment Rules run smoothly without encountering this error. If you encounter any other SCCM deployment issues, be sure to check out our other articles for solutions.
by Mark | Feb 27, 2016 | Features, Patch Releases, SCCM
An update version 3 has been released for Microsoft’s System Centre Configuration Manager 2012.
SCCM 2012 CU3
This update released by Microsoft fixes the following issues;
Administrator Console
- The Administrator Console may take longer than expected to expand different nodes, such as the All Users or All Devices nodes. This occurs when the console is installed on a touch-screen enabled computer.
- The Create Task Sequence Wizard generates an Unhandled exception when the Configuration Manager Console is installed on a computer that is running Windows 10 version 1511.
- The Configuration Manager console exits unexpectedly when the Task Sequence Editor is used to change a Microsoft Recovery (Windows RE) partition. Additionally, you receive an exception that resembles the following:
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
The Configuration Manager console exits unexpectedly when you try to add a custom icon for an application that’s available in the Application Catalog. This only occurs if the FIPS local/group security policy, ‘System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing’, is enabled on the computer that is running the console.
Operating system deployment
- A task sequence may continue for an application installation failure, even if the Continue on error option is not selected in the task sequence properties. This applies to task sequences installing applications that use a dynamic variable list.
- A task sequence will try to reinstall applications already installed by using a dynamic variable list if one of the applications is configured to restart the computer. For example, if the third in a list of 3 applications requires a restart, the first and second applications in the list will try to install again after the restart.
Use of the pre-provision BitLocker task sequence step during an operating system deployment results in the Trusted Platform Module (TPM) having a status of Ready for use, with reduced functionality.
Configuration Manager Client
- Applications removed from a Mac client computer continue to appear in the Installed Software node of hardware inventory for that client.
Microsoft Intune and mobile device management
- In a Configuration Manager environment in which the Microsoft Exchange Server connector is configured for use with Microsoft Exchange Server 2013, mobile devices aren’t listed as expected in the All Mobile Devices node of the administrator console. Additionally, errors that resemble the following are recorded in the EasDisc.log file on the Configuration Manager site server:
- The certificate required to connect to the Intune service cannot be renewed if the Microsoft Intune connector is installed to a server other than the site server, and proxy authentication is required for Internet access.
- Blocking Exchange ActiveSync access for an enrolled device fails. Errors that resemble the following are recorded in the EasDisc.log file on the site server after the blocking action fails:*** [42000][102][Microsoft][SQL Server Native Client 11.0][SQL Server]Incorrect syntax near ‘IsUIBlocked’.ERROR: UpdateDeviceAccessState: Execute() failed.
Site Systems
- The client automatic upgrade policy is refreshed after every restart of the SMS Executive service, even when no properties have changes. Entries that resemble the following are recorded in the hman.log file on the site server.
Handle auto-upgrade client configuration changes
Update auto-upgrade client configurations
- The State Systems component does not process messages that are generated by the Certificate Registration Point site system role if that server is configured to use a non-US date format. Errors that resemble the following are recorded in the statesys.log file on the site server:
SQL MESSAGE: spProcessStateReport – Error: Message processing encountered a SQL error 241 at record 1 for TopicType 5001: “Conversion failed when converting date and/or time from character string.”, Line 0 in procedure “”
- The SMS Executive service may exit unexpectedly when it processes a NOIDMIF file that contains a Unicode character invalid for the codepage of the site server.
- The “Reassign Distribution Point” migration task may stop responding when it tries to reassign a distribution point from a Configuration Manager 2007 secondary site. This occurs if the database record for the 2007 distribution point is removed and replicated to the primary site before the new record is added.
- The WMI Provider Host (WmiPrvSE.exe) hosting the Configuration Manager Provider (SMSProv) may exceed its memory quota on a site that processes lots of status messages from a custom application. This can result in a loss of connectivity through the Configuration Manager console until the server hosting the provider is restarted.
- Queries, and query-based collections that use the Windows Update Agent Version as criteria return unexpected results for Windows 10-based computers. This is because the Windows Update Agent Version in hardware inventory data is reported incorrectly in the 6.x range, such as 6.0.10240.16397 instead of the 10.x range, such as 10.0.10240.16397
Software distribution and content management
- 3120338 Content can’t be downloaded from Cloud-Based Distribution Points System Center 2012 Configuration Manager Service Pack 2 when BranchCache is enabled
- Applications deployed to a device that uses the Primary Device global condition will fail if the primary user has an apostrophe in their name.
- Distribution Points configured for HTTPS communications will be reset to use HTTP communications after other site properties are changed. For example, installing a new Software Update Point can trigger the Distribution Point to revert to HTTP communications. Other Distribution Point settings may also change.
- 3123884 Application installation fails from the Company Portal in System Center 2012 Configuration Manager
Settings management
- 3118485 “Setting Discovery Error” is returned for SQL Server 2014 Configuration Items in System Center Configuration Manager
- A Configuration Item (CI) that uses a Setting Type of SQL query will only evaluate against the first instance of a SQL Server even if the “All Instances” option is checked in the CI properties.
Additional changes that are included in this update
Endpoint Protection
- 3041687 Revised February 2015 anti-malware platform update for Endpoint Protection clients
Supported operating systems
- Mac OS X 10.11 can be targeted as a client platform for the following features:
Application Management
Settings Management
Software updates management / operating system deployment
- A new optional task sequence variable, SMSTSWaitForSecondReboot, is available to better control client behavior when a software update installation requires two restarts. This is in addition to changes released with System Center 2012 Configuration Manager SP2 to improve handling of unexpected restarts, as documented in Install Software Updates. This variable should be set before the “Install Software Updates” step to prevent a task sequence from failing because of a “double reboot” of a software update.SMSTSWaitForSecondReboot is a value in seconds that specifies how long the task sequence execution process should pause after the computer restarts to allow for sufficient time for a second restart to occur. For example, setting SMSTSWaitForSecondReboot to 600 results in a pause of 10 minutes after a restart before additional task sequence steps execute. This can be useful when hundreds of updates are being applied in a single “Install Software Updates” task sequence step. The value can be raised or lowered , depending on the volume of updates in your environment. If later task sequence steps trigger a computer restart, a second SMSTSWaitForSecondReboot variable can be set to reduce the wait down back to 0. This makes sure there are no additional delays after software updates are applied.
To download this Hotfix, visit the Microsoft site here
by Mark | Feb 27, 2016 | How To
The trust relationship between this workstation and the primary domain failed.
Have you ever encountered the error message, “The trust relationship between this workstation and the primary domain failed”? This can be a frustrating issue for IT administrators and end-users alike. But don’t worry! In this article, we’ll dive deep into the reasons behind this error and provide actionable solutions to fix it. Along the way, we’ll discuss domain environments, trust relationships, and how to prevent this problem from occurring in the future.
Understanding Trust Relationships in a Domain Environment
The trust relationship between this workstation and the primary domain failed error occurs when there’s a disruption in the trust relationship between the computer and the domain controller. Here are some common causes of this error:
- Password synchronization issues: If the computer’s password doesn’t match the password stored in the domain controller, it can cause trust relationship issues.
- Time synchronization issues: If the time on the computer and the domain controller is out of sync, it can cause trust relationship issues.
- Computer account deletion: If the computer account is deleted from the Active Directory, it can cause trust relationship issues.
- The computer account password in Active Directory (AD) is not in sync with the password stored on the local machine.
- Corruption of the local security database on the workstation.
- Issues with DNS configuration or connectivity.
Symptoms caused by this Error
Symptoms of “The trust relationship between this workstation and the primary domain failed”:
Here are some symptoms that indicate that you’re facing “The trust relationship between this workstation and the primary domain failed” error:
- Unable to log in to the computer with domain credentials.
- Unable to access network resources.
- Unable to access shared folders.
- Error message: “The trust relationship between this workstation and the primary domain failed.”
- Applications that rely on domain authentication fail to function properly.
- Event logs display error messages related to trust relationship failures.
How to Fix “The trust relationship between this workstation and the primary domain failed”
There are several solutions to resolve the “The trust relationship between this workstation and the primary domain failed” error. Here are some of them:
Solution 1: Reset computer account password:
- Log in to the computer with local administrator credentials.
- Open Command Prompt as an administrator.
- Type the following command and press Enter: netdom resetpwd /s:domaincontroller /ud:domainadmin /pd:*
Note: Replace “domaincontroller” with the name of your domain controller and “domainadmin” with the domain administrator account.
Solution 2: Rejoin the computer to the domain:
- Log in to the computer with local administrator credentials.
- Open Control Panel and navigate to System.
- Click on “Change settings” next to “Computer name, domain, and workgroup settings.”
- Click on “Change” next to “To rename this computer or change its domain or workgroup, click Change.”
- Select “Domain” and enter the domain name.
- Enter the domain administrator credentials.
- Restart the computer.
Solution 3: Restore the computer account:
- Log in to the domain controller with domain administrator credentials.
- Open Active Directory Users and Computers.
- Navigate to the “Computers” container.
- Right-click on the computer account and select “Restore.”
Solution 4: Increase the Time out period of the computer account:
- Increase the computer account password age or even disable password changes altogether to prevent this error from occurring in the future. To do so, you’ll need to set the following registry key:
- KEY: HKEY_LOCAL_MACHINE – SYSTEM – CurrentControlSet – Services – Netlogon – Parameters Property: DisablePasswordChange Value: 1
This will disable password changes for the computer account, ensuring that the machine’s account password remains the same even if you restore an older snapshot.
Preventing Trust Relationship Failures
Preventing trust relationship failures is crucial to maintaining a smooth domain environment. Here are some best practices to help you avoid these issues:
Regularly Updating Passwords
Ensure that computer account passwords are regularly updated in both Active Directory and on the local workstations. By default, this happens every 30 days, but you can modify the password update interval if necessary.
Monitoring Active Directory Health
Keep an eye on the overall health of your Active Directory environment. Regularly monitor domain controllers, replication, and system logs to catch potential issues before they escalate into trust relationship failures.
Ensuring Proper DNS Configuration
Proper DNS configuration is vital for the smooth functioning of a domain environment. Make sure that workstations are using the correct DNS servers and that domain controllers have properly configured DNS settings.
FAQs
What is a trust relationship between a computer and a domain?
A trust relationship is established between a computer and a domain when the computer joins the domain. This trust allows the computer to access network resources and authenticate users.
Can I prevent “The trust relationship between this workstation and the primary domain failed” error?
Yes, you can prevent this error by ensuring that the computer’s time and password are synchronized with the domain controller.
How can I avoid trust relationship issues in the future?
You can avoid trust relationship issues by regularly resetting computer account passwords, synchronizing time between the computer and domain controller, and ensuring that the computer is not deleted from the Active Directory.
Can a non-administrator account resolve the “The trust relationship between this workstation and the primary domain failed” error?
No, a non-administrator account cannot resolve this error. You need to have local administrator or domain administrator credentials to resolve this error.
What causes a trust relationship to fail?
Trust relationship failures can occur due to reasons such as password synchronization issues, disabled or deleted computer accounts, DNS configuration problems, or corruption of the local security database.
How can I reset a computer account in Active Directory?
You can reset a computer account in Active Directory using the Active Directory Users and Computers console or PowerShell.
What is the Test-ComputerSecureChannel cmdlet in PowerShell?
The Test-ComputerSecureChannel cmdlet is a PowerShell command that allows you to test and repair the trust relationship between a workstation and the primary domain.
How can I prevent trust relationship failures?
To prevent trust relationship failures, ensure regular computer account password updates, monitor Active Directory health, and maintain proper DNS configuration.
Conclusion:
“The trust relationship between this workstation and the primary domain failed” error can be frustrating, but it’s a common issue faced by many computer users. This error occurs when there’s a disruption in the trust relationship between the computer and the domain controller. You can resolve this error by resetting the computer account password, rejoining the computer to the domain, or restoring the computer account. By following these solutions, you can prevent this error from occurring in the future. Remember to ensure that the computer’s time and password are synchronized with the domain controller to avoid trust relationship issues.
by Mark | Feb 27, 2016 | How To, VMWare
As a system administrator, you might face situations where a Domain Controller (DC) in your network fails due to hardware issues or software corruption. In such cases, restoring the DC from a snapshot can be a lifesaver. A snapshot is an image of the system’s state at a particular point in time, and restoring from it can bring back the system to that state. In this article, we will discuss how to restore a Domain Controller from a snapshot, step by step.
Understanding the Importance of Domain Controllers
Before we jump into the process of restoring a Domain Controller from a snapshot, let’s first understand why DCs are crucial for a network. In simple words, a Domain Controller is a server that manages network security and enables users to access shared resources, such as printers and files, on the network. It is the backbone of the Active Directory (AD) infrastructure, which is responsible for authentication and authorization in a Windows environment.
Reverting a snapshot of an active Domain Controller can be a risky and problematic issue.
If you are considering using this procedure it should be your very LAST option. This is not a supported Microsoft procedure and use of it could cause fatal issues to Active Directory.
Reassess your environment and take the proper steps to ensure this recovery model doesn’t have to be used again.
Use at your own risk!
What are the risks with doing this?
The risks of reverting a snapshot of a Domain Controller are significant and can have severe consequences for an organization’s Active Directory infrastructure. Some of the potential risks include:
-
Data loss: Reverting a snapshot of an Active Domain Controller can result in data loss, as the snapshot may not contain all of the latest changes to the Active Directory.
-
Active Directory corruption: The Active Directory database may become corrupted during the snapshot revert process, leading to issues with authentication, authorization, and other critical services.
-
Replication problems: The snapshot revert process can cause problems with replication between Domain Controllers, leading to inconsistencies in the Active Directory data across different servers.
-
Service disruptions: The snapshot revert process can result in disruptions to critical services, such as DNS, that depend on the Active Directory.
-
Security risks: The snapshot revert process can result in security risks, as it may expose sensitive data or compromise the security of the Active Directory infrastructure.
It is important to carefully consider the potential risks and consequences before attempting to revert a snapshot of an Active Domain Controller. It is recommended to only use this procedure as a last resort, and to thoroughly research and understand the potential risks before proceeding.
Preparing for the Restoration
Before you start the restoration process, you need to ensure that you have a snapshot of the Domain Controller that you want to restore. It is essential to note that restoring a DC from a snapshot is a risky process and should be performed only when no other options are available. Moreover, you must have a proper backup and recovery plan in place to avoid any data loss during the restoration.
Steps to revert a Domain Controller Snapshot
1) Revert to your last known good snapshot
2) Disable your network card so that it is unable to talk to the network
3) Note the value of your Invocation Id
- From a command prompt run the following command
- Repadmin /showrepl
4) Reboot your Domain Controller and make sure you boot into Directory Services Restore Mode
5) Stop the NTFRS service
6) From a command prompt start Regedit
- Drill down to HKLM – System – CurrentControlSet – Services – NTDS – Parameters
- Modify the RegKey “Database restored from backup” = 1
- If this RegKey doesn’t exist create one as a DWORD and set to a 1
- If the RegKey DSA Previous Restore Count exists in the same path, note its value. Upon reboot it should increment by one. If it didn’t exist it should be created and it should be set to a value of 1.
- Drill down to HKLM – SYSTEM – CurrentControlSet – Services – NtFrs – Parameters – Backup – Restore – Process
- Modify the RegKey BurFlags to D2
7) Reboot the server
8) Log back in to the Domain Controller
- Verify that the Invocation Id has changed
- In the Event Log look for the Event Id 1109 (AD restored from backup)
9) If both events have occurred in bullet point 8 then, enable the network card again
Best Practices for Restoring a Domain Controller from a Snapshot
Here are some best practices that you should follow while restoring a Domain Controller from a snapshot:
Best Practice 1: Ensure the Snapshot is Consistent
Make sure that the snapshot is consistent and the system is shut down gracefully before taking the snapshot.
Best Practice 2: Test the Snapshot
Before performing the actual restoration, test the snapshot on a test environment to ensure that the restoration process goes smoothly.
Best Practice 3: Have a Backup Plan in Place
Always have a backup plan in place and test it regularly to ensure that it is effective.
Best Practice 4: Monitor the DC after Restoration
Monitor the Domain Controller closely after the restoration to ensure that it is functioning correctly.
Conclusion
Restoring a Domain Controller from a snapshot can be a lifesaver in critical situations. However, it is a risky process and should be performed only when no other options are available. It is essential to have a proper backup and recovery plan in place and follow the best practices while restoring a Domain Controller
