Issue The host goes into an un-responsive state due to: “Bootbank cannot be found at path ‘/bootbank” and boot device is in an APD state.
This issue is seen due to the boot device failing to respond & enter APD state (All paths down). Some cases, Host goes to non-responsive state & shows disconnected from vCenter.
As of 7.0 Update 1, the format of the ESX-OSData boot data partition has been changed. Instead of using FAT it is using a new format called VMFS-L. This new format allows much more and faster I/O to the partition. The level of read and write traffic is overwhelming and corrupting many less capable SD cards.
The action plan for future resolution would be to replace the SD card/s with a capable device/disk. Per the best practices mentioned on Installation guide.
The version 7.0 Update 2 VMware ESXi Installation and Setup Guide, page 19, specifically says “As even read-only workloads can cause problems on low-end flash devices, you should install ESXi only on high-endurance flash media“.
A remote code execution vulnerability exists in Microsoft Exchange software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user. An attacker could then install programs; view, change, or delete data; or create new accounts.
Exploitation of the vulnerability requires that a specially crafted email be sent to a vulnerable Exchange server.
The security update addresses the vulnerability by correcting how Microsoft Exchange handles objects in memory.
Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 21
On March 20, 2018 Microsoft has released two new quarterly updates:
Exchange 2016 Cumulative Update 9 (CU9)
Exchange 2013 Cumulative Update 20 (CU20)
There aren’t too many new features in these CUs. The most important ‘feature’ is that TLS 1.2 is now fully supported (most likely you already have TLS 1.2 only on your load balancer). This is extremely supported since Microsoft will support TLS 1.2 ONLY in Office 365 in the last quarter of this year (see the An Update on Office 365 Requiring TLS 1.2 Microsoft blog as well).
Support for .NET Framework 4.7.1, or the ongoing story about the .NET Framework. The .NET Framework 4.7.1 is fully supported by Exchange 2016 CU9 and Exchange 2013 CU20. Why is this important? For the upcoming CUs in three months (somewhere in June 2018) the .NET Framework 4.7.1 is mandatory, so you need these to be installed in order to install these upcoming CUs.
Please note that .NET Framework 4.7 is NOT supported!
If you are currently running an older CU of Exchange, for example Exchange 2013 CU12, you have to make an intermediate upgrade to Exchange 2013 CU15. Then upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2013 CU20. If you are running Exchange 2016 CU3 or CU4, you can upgrade to .NET Framework 4.6.2 and then upgrade to Exchange 2016 CU9.
If you are coming from a recent Exchange 2013 CU, there are no schema changes since the schema version (rangeUpper = 15312) hasn’t changed since Exchange 2013 CU7. However, since there can be changes in (for example) RBAC, it’s always a good practice to run the Setup.exe /PrepareAD command. For Exchange 2016, the schema version (rangeUpper = 15332) hasn’t changed since Exchange 2016 CU7.
As always, check the new CUs in your lab environment before installing into your production environment!!
Exchange Server 2013 enters the Extended Support phase of product lifecycle on April 10th, 2018. During Extended Support, products receive only updates defined as Critical consistent with the Security Update Guide. For Exchange Server 2013, critical updates will include any required product updates due to time zone definition changes.
1. Edit DeployWiz_SelectTS.vbs 2. Add after Function ValidateTSList and Dim oTS Dim oItem Dim sCmd Set Oshell = createObject(“Wscript.shell”) 3. Add between End if and End Function sCmd = “wscript.exe “”” & oUtility.ScriptDir & “\ZTIGather.wsf””” oItem = oSHell.Run(sCmd, , true)
Support for .Net 4.6.1 is now available for Exchange Server 2016 and 2013 with these updates. We fully support customers upgrading servers running 4.5.2 to 4.6.1 without removing Exchange. We recommend that customers apply Exchange Server 2016 Cumulative Update 2 or Exchange Server 2013 Cumulative Update 13 before upgrading .Net FrameWork. Servers should be placed in maintenance mode during the upgrade as you would do when applying a Cumulative Update. Support for .Net 4.6.1 requires the following post release fixes for .Net as well.
Note: .Net 4.6.1 installation replaces the existing 4.5.2 installation. If you attempt to roll back the .Net 4.6.1 update, you will need to install .Net 4.5.2 again.
AutoReseed Support for BitLocker
Beginning with Exchange 2013 CU13 and Exchange 2016 CU2, the Disk Reclaimer function within AutoReseed supports BitLocker. By default, this feature is disabled. For more information on how to enable this functionality, please seeEnabling BitLocker on Exchange Servers.
SHA-2 Support for Self-Signed Certificates
The New-ExchangeCertificate cmdlet has been updated to produce a SHA-2 certificate for all self-signed certificates created by Exchange. Creating a SHA-2 certificate is the default behaviour for the cmdlet. Existing certificates will not automatically be regenerated but newly installed servers will receive SHA-2 certificates by default. Customers may opt to replace existing non-SHA2 certificates generated by previous releases as they see fit.
Migration to Modern Public Folder Resolved
The issue reported in KB3161916 has been resolved.
This cumulative update fixes the following issues:
This will show you how to configure your environment for BitLocker, the disk volume encryption built into Windows 10 Enterprise and Windows 10 Pro, using MDT. BitLocker in Windows 10 has two requirements in regard to an operating system deployment:
A protector, which can either be stored in the Trusted Platform Module (TPM) chip, or stored as a password.
To configure your environment for BitLocker, you will need to do the following:
Configure Active Directory for BitLocker.
Download the various BitLocker scripts and tools.
Configure the rules (CustomSettings.ini) for BitLocker.
Configure Active Directory for BitLocker
To enable BitLocker to store the recovery key and TPM information in Active Directory, you need to create a Group Policy for it in Active Directory. For this section, we are running Windows Server 2012 R2, so you do not need to extend the Schema. You do, however, need to set the appropriate permissions in Active Directory.
Depending on the Active Directory Schema version, you might need to update the Schema before you can store BitLocker information in Active Directory.
In Windows Server 2012 R2 (as well as in Windows Server 2008 R2 and Windows Server 2012), you have access to the BitLocker Drive Encryption Administration Utilities features, which will help you manage BitLocker. When you install the features, the BitLocker Active Directory Recovery Password Viewer is included, and it extends Active Directory Users and Computers with BitLocker Recovery information.
Figure 2. The BitLocker Recovery information on a computer object in the contoso.com domain.
Add the BitLocker Drive Encryption Administration Utilities
The BitLocker Drive Encryption Administration Utilities are added as features via Server Manager (or Windows PowerShell):
On DC01, log on as CONTOSO\Administrator, and, using Server Manager, click Add roles and features.
On the Before you begin page, click Next.
On the Select installation type page, select Role-based or feature-based installation, and click Next.
On the Select destination server page, select DC01.contoso.com and click Next.
On the Select server roles page, click Next.
On the Select features page, expand Remote Server Administration Tools, expand Feature Administration Tools, select the following features, and then click Next:
Enable the Turn on TPM backup to Active Directory Domain Services policy.
(Don’t forget to disable Secure Boot & Enable the secure boot again after deployment is succes vol!!)
Set permissions in Active Directory for BitLocker
In addition to the Group Policy created previously, you need to configure permissions in Active Directory to be able to store the TPM recovery information. In these steps, we assume you have downloaded the Add-TPMSelfWriteACE.vbs script from Microsoft to C:\Setup\Scripts on DC01.
On DC01, start an elevated PowerShell prompt (run as Administrator).
Configure the permissions by running the following command:
Figure 4. Running the Add-TPMSelfWriteACE.vbs script on DC01.
Add BIOS configuration tools from Dell, HP, and Lenovo
If you want to automate enabling the TPM chip as part of the deployment process, you need to download the vendor tools and add them to your task sequences, either directly or in a script wrapper.
Add tools from Dell
The Dell tools are available via the Dell Client Configuration Toolkit (CCTK). The executable file from Dell is named cctk.exe. Here is a sample command to enable TPM and set a BIOS password using the cctk.exe tool:
cctk.exe --tpm=on --valsetuppwd=Password1234
Add tools from HP
The HP tools are part of HP System Software Manager. The executable file from HP is named BiosConfigUtility.exe. This utility uses a configuration file for the BIOS settings. Here is a sample command to enable TPM and set a BIOS password using the BiosConfigUtility.exe tool:
And the sample content of the TPMEnable.REPSET file:
Activate Embedded Security On Next Boot
Embedded Security Activation Policy
F1 to Boot
Allow user to reject
Embedded Security Device Availability
Add tools from Lenovo
The Lenovo tools are a set of VBScripts available as part of the Lenovo BIOS Setup using Windows Management Instrumentation Deployment Guide. Lenovo also provides a separate download of the scripts. Here is a sample command to enable TPM using the Lenovo tools:
The Microsoft Deployment Toolkit (MDT) 2013 Update 2 (6.3.8330) is now available on the Microsoft Download Center. This update requires the Windows Assessment and Deployment Kit (ADK) for Windows 10, available on the Microsoft Hardware Dev Center. (Note that there are known issues with the v1511 release of the Windows 10 ADK and System Center Configuration Manager; these issues do not directly affect MDT although may still impact ZTI or UDI scenarios.)
MDT 2013 Update 2 is primarily a quality release; there are no new major features. The following is a summary of the significant changes in this update:
Security- and cryptographic-related improvements:
Relaxed permissions on newly created deployment shares (still secure by default, but now also functional by default)
Creating deployment shares via Windows PowerShell adds same default permissions
Updated hash algorithm usage from SHA1 to SHA256
Includes the latest Configuration Manager task sequence binaries
Enhanced user experience for Windows 10 in-place upgrade task sequence
Enhanced split WIM functionality
Fixed OSDJoinAccount account usage in UDI scenario
Fixed issues with installation of Windows 10 language packs
Various accessibility improvements
Monitoring correctly displays progress for all scenarios including upgrade
Improvements to smsts.log verbosity
There are no other new release notes or significant known issues. See the previous post for more information as much of it is still applicable (other than the fix list above).
In anticipation of some questions that you may have about this release (or MDT in general):
Q: Should I expect a release of MDT with every new Windows 10 and/or Configuration Manager build release?
No. We shipped multiple MDT releases this year due to the timing of Windows 10 and Configuration Manager releases, but do not intend to keep that same cadence going forward.
Q: What branches of Windows 10 does MDT support?
MDT supports both the current branch of Windows 10 as well as the long-term servicing branch.
Q: What branches of System Center Configuration Manager does MDT support?
For ZTI and UDI scenarios MDT 2013 Update 2 supports the current branch of System Center Configuration Manager (currently version 1511) for an integrated solution for deploying Windows 10 current branch as well as prior Windows versions.
Q: When is the next planned release of MDT?
We do not currently have a timeframe. We will release any tactical changes as needed which may be required to support new builds of Windows 10 or Configuration Manager, but do not currently expect this to be needed.
Q: Is this the last release of MDT?
No, we will continue to iterate and invest in the product.
Q: Why is it still “MDT 2013” when the year is almost 2016?
Two primary reasons. First, we have only made minor changes to MDT which in our opinion does not constitute a major version revision. Second, per the MDT support lifecycle, a new major version will drop support for MDT2012 Update 1 which still supports legacy platforms.