One of the scripts I've often used when trying gather information about a current Exchange environment prior to performing a migration is the Get-ExchangeEnvironmentReport.ps1 PowerShell script written by Steve Goodman.  The information provided by the report provides great information that would allow me to get a good understanding of the current Exchange topology as well as the mailbox databases.  If you are unfamiliar with this script, further details about the script can be found in the following links:

Generate Exchange Environment Reports using Powershell
https://gallery.technet.microsoft.com/office/Generate-Exchange-2388e7c9

Generate Exchange Environment Reports using Powershell
http://www.stevieg.org/2011/06/exchange-environment-report/

This script could be scheduled to automatically run via the Task Scheduler and this post serves to provide the configuration for the action which sometimes can be difficult to find.  Note that I won’t go into the details of creating the scheduled task as that could be found in one of my previous posts here:

Setting up vCheck PowerShell health check script in Task Scheduler to automatically run daily
http://terenceluk.blogspot.com/2017/03/setting-up-vcheck-powershell-health.html

The following is the syntax required to configure the action:

Program/script: powershell.exe

Add arguments (option): -command ". 'E:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; . 'C:\PS-Scripts\Get-ExchangeEnvironmentReportModified.ps1'

Problem

You have a Cisco Wireless Controller setup to use a Microsoft Network Policy (RADIUS) server to authenticate wireless clients via 802.1X and while Android devices and all Windows clients that are joined to the domain have no issues connecting to the network, non-domain joined Windows 10 workstations are unable to. 

Attempting to join the network with a non-domain joined Windows 10 device shows the following Audit Failure log written in the Security logs of the NPS server:

Log Name: Security

Source: Microsoft Windows security

Event ID: 6273

Level: Information

Network Policy Server denied access to a user.

Contact the Network Policy Server administrator for more information.

User:
     Security ID:            CONTOSO\tluk
     Account Name:            CONTOSO\tluk
     Account Domain:            CONTOSO
     Fully Qualified Account Name:    CONTOSO\tluk

Client Machine:
     Security ID:            NULL SID
     Account Name:            -
     Fully Qualified Account Name:    -
     OS-Version:            -
     Called Station Identifier:        00-17-df-a8-e0-50:CONTOSO_Corp
     Calling Station Identifier:        60-57-18-a7-ea-18

NAS:
     NAS IPv4 Address:        192.168.220.254
     NAS IPv6 Address:        -
     NAS Identifier:            Cisco_7d:fe:e4
     NAS Port-Type:            Wireless - IEEE 802.11
     NAS Port:            13

RADIUS Client:
     Client Friendly Name:        CONTOSO Test
     Client IP Address:            192.168.220.254

Authentication Details:
     Connection Request Policy Name:    CONTOSO
     Network Policy Name:        Secure Wireless Connections 3
     Authentication Provider:        Windows
     Authentication Server:        CONTOSODC01.Contoso.com
     Authentication Type:        PEAP
     EAP Type:            -
     Account Session Identifier:        35393361643862372F36303A35373A31383A61373A65613A31382F3739383139
     Logging Results:            Accounting information was written to the local log file.
     Reason Code:            16
     Reason:                Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

The error presented in Windows 10 during the login is shown in the following screenshots:

Verifying and connecting

Can’t connect to this network

Solution

One of the reasons why this error would be be presented to non domain joined Windows 10 client is if the NPS / RADIUS server is configured with a certificate issued by an internal Microsoft CA that is not trusted by the Windows 10 device since it is not joined to the domain.  The way around this is to either install the issuing Root CA certificate on the Windows 10 device or configure the SSID network manually and do validate the certificate.  The following outlines these steps:

Begin by opening the Network and Sharing Center then click on Set up a new connection or network:

Select Manually connect to a wireless network:

Fill in the appropriate configuration:

Once the new SSID network has been created, proceed by clicking on Change connection settings:

Click on the Security tab:

Click on the Settings button:

Uncheck the Verify the server’s identity by validating the certificate option:

Configure the above usually does the trick so that the following prompt is displayed the next time an attempt is made to connect:

However, if you continue to encounter the same error then proceed by clicking on the Advanced settings button:

Enable the Specify authentication mode: option:

Change the configuration to User authentication then click on Save credentials:

Enter the appropriate credentials:

The SSID should now no longer prompt for credentials and will automatically connect to the SSID network with the saved credentials.

I’ve been asked several times in the past about how to configure a NetScaler virtual load balancing server to redirect traffic to another URL based on the incoming source IP address so this post serves to demonstrate the process.

Step #1 – Create the Responder Action

Begin by navigating to AppExpert > Responder > Actions and click the Add button to create the responder action to execute when a policy is met:

In the Create Responder Action window, fill in the following fields as required:

Name: A name that represents the redirect – Redirect_USA_Subnets_Action

Type: Redirect

Expression: Enter the URL you would like to redirect requests to with quotes – “https://www.someURL.com”

Response Status Code: 302

Step #2 – Create the Responder Policy

Navigate to AppExpert > Responder > Policies and click the Add button to create the responder police that will execute the action that was previously created when a requirement is met:

In the Create Responder Policy window, fill in the following fields as required:

Name: A name that represents the redirect – Redirect_USA_Subnets_Action

Action: The previous action created – Redirect_USA_Subnets_Action

Expression: Enter the required IP address or subnet with the expressions:

CLIENT.IP.SRC.EQ(x.x.x.x) || CLIENT.IP.SRC.IN_SUBNET(x.x.x.0/24)

An example of would be:

CLIENT.IP.SRC.EQ(10.43.3.136) || CLIENT.IP.SRC.IN_SUBNET(162.221.215.0/24) || CLIENT.IP.SRC.IN_SUBNET(195.130.217.0/24) || CLIENT.IP.SRC.IN_SUBNET(91.220.42.0/24) || CLIENT.IP.SRC.IN_SUBNET(185.58.84.0/22)

Step #3 – Assign Responder Policy to Virtual Server

Navigate to Traffic Management > Load Balancing > Virtual Servers and edit the properties of the virtual server you would like to redirect traffic based on incoming source IP address:

If there are already policies assigned, scroll down to the Policies section and click on the + button or if there are no policies applied then click on the Policies button listed on the right side of the page to add a new policy:

Configure the following and click Continue:

Choose Policy: Responder

Choose Type: Request

In the Choose Type options window, click on Click to select under Select Policy:

Select the Responder Policy that was created earlier:

Click on the Bind button to bind the policy to the virtual server:

Save the configuration by clicking on the Done button:

The NetScaler will now redirect any traffic coming in for the specified IPs to the alternate URL.

Problem

You have a Windows 2012 R2 server virtual machine with multiple disks that is formatted with the ReFS file system and you have just one of the disks at the hypervisor level then proceed to extend it within DiskManagement:

Attempting to complete the Extend Volume Wizard throws the following error:

Disk Management

There is not enough space available on the disk(s) to complete this operation.

The expansion of the disk fails.  You attempt to use diskpart but receive the same error:

Virtual Disk Service error:

There is not enough usable space for this operation.

You attempt to expand the disk by 1MB but the results are the same:

Solution

I’m not sure whether this is a bug in the earlier versions of Windows 2012 R2 and ReFS but expanding the disk by 1000MB completes successfully:

10000MB also works:

Sames goes for 100000MB:

With 52.60GB of Unallocated space left, leaving the Select the amount of space in MB as the default (maximum) completes successfully:

Problem

You’ve recently updated the certificates for your Exchange 2016 servers:

You notice that the ECP / EAC page no longer load properly upon successfully logging in after reassigning the new certificate, deleting the old certificate and restarting the server:

Reviewing the event logs show the following error constantly logged on the Exchange server(s):

Log Name: System

Source: HttpEvent

Event ID: 15021

Level: Error

An error occurred while using SSL configuration for endpoint 0.0.0.0:444. The error status code is contained within the returned data.

Solution

The error above could be caused by the port 444 SSL certificate binding continuing to reference the old deleted certificate.  To determine whether this is the case, start the command prompt and execute the following command:

netsh http show sslcert

The command should list the SSL certificate bindings for the server similar to the following:

C:\>netsh http show sslcert

SSL Certificate bindings:

-------------------------

IP:port : 0.0.0.0:443

Certificate Hash : d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 0.0.0.0:444

Certificate Hash : c71d3d6f9673dcec57d8c76602562d58bd69d9b9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 0.0.0.0:8172

Certificate Hash : 403a6eac00d494c03288a1df779aeae7a131886f

Application ID : {00000000-0000-0000-0000-000000000000}

Certificate Store Name : MY

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

IP:port : 127.0.0.1:443

Certificate Hash : d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

Certificate Store Name : My

Verify Client Certificate Revocation : Enabled

Verify Revocation Using Cached Client Certificate Only : Disabled

Usage Check : Enabled

Revocation Freshness Time : 0

URL Retrieval Timeout : 0

Ctl Identifier : (null)

Ctl Store Name : (null)

DS Mapper Usage : Disabled

Negotiate Client Certificate : Disabled

Reject Connections : Disabled

C:\>

The output we’re interested in are as follows:

IP:port : 0.0.0.0:444

Certificate Hash : c71d3d6f9673dcec57d8c76602562d58bd69d9b9

-------------------------------------------------------------------------------------------------------------------

Also make a note of the following information which we will need later:

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

-------------------------------------------------------------------------------------------------------------------

Confirm that the IP:port : 0.0.0.0:444 is indeed referencing the old certificate by reviewing the thumbprint of the old deleted certificate with the Certificate Hash:

Note that the thumbprint in the screenshot above matches the certificate hash generated above.  Once confirmed that the IP:port : 0.0.0.0:444 is indeed referencing the old certificate, proceed to delete the binding by executing the following command:

netsh http delete sslcert ipport=0.0.0.0:444

Execute netsh http show sslcert to confirm that the binding has been deleted:

Proceed with creating the binding with the new certificate by executing a command that references the ApplicationID that we made a note of earlier:

Application ID : {4dc3e181-e14b-4a21-b022-59fc669b0914}

… and obtaining the thumbprint of the new certificate that we’ll be using:

Use the information above to execute the following command:

netsh http add sslcert ipport=0.0.0.0:444 certhash=d0da0b35cf91c55b91a10755c0b4b11dfb1d3ff9 appid="{4dc3e181-e14b-4a21-b022-59fc669b0914}"

The errors written in the event logs should now be corrected.  Proceed to repeat these steps on all of the affected Exchange servers.

Problem

You’re in the process of migrating mailboxes from Exchange 2010 to Exchange 2016 with both a live as well as an archive mailbox and while some mailboxes successfully move to the new databases, you noticed that others remains in Syncing status indefinitely:

Expanding the More Details… option show the synchronization has stalled for quite some time:

Executing the cmdlet Get-MoveRequest | Get-MoveRequestStatstics -Format-Table -AutoSize displays the StatusDetail StalledDueToTarget_MailboxCapacityExceeded:

Executing the cmdlets:

Get-MoveRequest administrator | FL

… or:

Get-MoveRequest | Get-MoveRequestStatistics | FL

… does not provide additional information.

Reviewing the properties of the migration job and clicking on Report: Download the report for this user:

… displays a report with the following log output:

7/2/2017 10:14:11 AM [CONTBMEXMB01] '' created move request.
7/2/2017 10:14:11 AM [CONTBMEXMB01] '' allowed a large amount of data loss when moving the mailbox (50 bad items, 0 large items).
7/2/2017 11:07:56 AM [CONTBMEXMB01] Relinquishing job because of large delays due to unfavorable server health or budget limitations with a request throttling state 'StalledDueToTarget_Processor'.
7/2/2017 11:51:16 AM [CONTBMEXMB01] Relinquishing job because of large delays due to unfavorable server health or budget limitations with a request throttling state 'StalledDueToTarget_Processor'.
7/2/2017 11:15:00 PM [CONTBMEXMB01] '' suspended move request.
7/2/2017 11:15:02 PM [CONTBMEXMB01] Suspending job.
7/2/2017 11:15:02 PM [CONTBMEXMB01] Relinquishing job.
7/3/2017 10:04:41 AM [CONTBMEXMB01] '' resumed move request.
7/3/2017 10:04:45 AM [CONTBMEXMB01] Job resumed with status 'Queued'.
7/3/2017 10:04:45 AM [CONTBMEXMB01] Relinquishing job.

Attempting to log onto the Exchange 2016 server and adjusting the parameters MaxActiveJobsPerSourceMailbox and MaxActiveJobsPerTargetMailbox in the configuration file MSExchangeMailboxReplication.exe.config located in the directory E:\Program Files\Microsoft\Exchange Server\V15\Bin does not correct the issue:

Solution

Attempting to search for the error messages:

StalledDueToTarget_MailboxCapacityExceeded:

… and:

StalledDueToTarget_Processor

… did not return any helpful posts and what ended up being the problem was the archive mailbox server we were using to move the archive mailboxes to.  The server’s CPU utilization wasn’t particularly high (2%), memory usage was average (90%) but the server uptime was 82 days and there were pending Windows patches asking for a reboot. Previous mailboxes that were stalled would successfully completed after the server restart:

Hope this helps anyone who may encounter this issue and unable to find any useful information on the internet.

Problem

You attempt to expand a hard disk of a vSphere Replication replicated virtual machine but immediately receive the following error:

Reconfigure virtual machine

Invalid or unsupported virtual machine configuration.

See the error stack for details on the cause of this problem.

vSphere Replication does not support changing the length of a replicated disk.

Solution

The reason why the error is thrown is because vSphere Replication prevents sizing changes to the protected copy of the virtual machine (source) when it is replicated to a recovery copy of the virtual machine (target).  This makes sense because the replication engine likely tracks the changes in a certain way where changing the disk size would cause issues.  VMware has released the following two KBs to explaining the steps required to expand a replicated virtual machine’s hard disk:

Resizing virtual machine disk files that are protected by vSphere Replication (VR) using VMware vCenter Site Recovery Manager (2042790)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042790

Cannot resize the vmdk files during replication which are protected by vSphere replication (2052883)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2052883

… but I find that the instructions aren’t completely clear so I thought I’d demonstrate the process with screenshots so there are no confusions.

Step #1 - Document Replicated Virtual Machine's vSphere Replication Configuration

Begin by documenting replicated virtual machine's vSphere Replication configuration because you will need this information when specifying the Target Location in one of the later steps (screenshots usually suffice assuming the path fits in the text field):

Ensure that you can read the full path of the Target Location:

The same applies to every Hard diskTarget Location field:

Document the Quiescing method configuration:

Document the Recovery Settings and I usually select Cancel to avoid unintentionally making any changes:

Step #2 - Rename the Replicated Virtual Machine's Datastore Folder(s)

Proceed to browsing the Target Location datastore of where the replicated virtual machine is stored.  Note that this is the replicated copy and NOT the live copy:

One of the reasons why it is important to document the Target Location of the replicated copy is because the VMDK files are not always stored in the same directory as the VMX files as shown in this example:

Proceed to rename the replicated copy's folder as such.  Remember that this is the replicated copy and NOT the live copy:

Rename any additional folders that store the replicated virtual machine's files:

Step #3 - Stop the Virtual Machine's Replication 

I find the step #2 outlined in the KB:

Cannot resize the vmdk files during replication which are protected by vSphere replication(2052883)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2052883

... unclear but it states:

2. Disable replication of the virtual machine you want to resize.

The fact that there is no disable option causes confusion.  Step #3 in the KB article:

Resizing virtual machine disk files that are protected by vSphere Replication (VR) using VMware vCenter Site Recovery Manager (2042790)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2042790

... is much clearer as it states:

3. Stop replication for the virtual machine at the protected site using the vSphere Replication User Interface (UI).

So with this in mind, proceed to right-clicking on the replicate virtual machine in the vSphere Replication console and select Stop:

Note that it is important to you have renamed the Target Location virtual machine folders.  From what I've seen, if the replicated VM was seeded then the target files would not be deleted but if the replicated VM was not seeded then the files would get deleted.

You should now see tasks executed under the Recent Tasks pane indicating replication is being disabled for the virtual machine:

The virtual machine should no longer be displayed once the operation completes.

Step #4 - Expand Source/Live Virtual Machine's VMDK

With replication stopped, you should now be able to expand the source/live virtual machine's VMDKs so proceed to expanding them to the size required.

Step #5 - Expand Target/Replicated Virtual Machine's VMDK

Since the target/replicated virtual machine is not inventoried on a host, expanding the drives will need to be done with the vmkfstools command.  Proceed by either accessing the console or SSH to a host that has access to the datastore and navigate to the directory of the renamed folders containing the replicated virtual machine files. 

**The ls -lah command can be used to display the files in the command line.

Once in the directory containing the files, proceed to increase the hard drive VMDK file with the command:

vmkfstools -x XXXGB <filenameOfVMDK>

A similar output below will be displayed upon successfully increasing the VMDK:

Refreshing the datastore browser will show the new size of the VMDK:

Continue by renaming the folder back to the original name:

Proceed to reconfigure replication for the virtual machine:

The default Target location that is used will most likely be different than the folder with the replicated VMDKs so use the previously documented configuration to select the same Target location as the original location:

Once the previous Target location has been configured, the amount of hard disks of the replicated virtual machine will now be displayed (there are 4 in this case):

Configure all of the hard disks to use the same folder as the previous location:

Selecting the folder with the existing replicated VMDK will display the following message:

Replication Seed Confirmation

Duplicate file found. Do you want to use this file as a seed?

Select Yes when receiving this prompt:

Continue and repeat the same procedure for the rest of the disks and the same Replication Seed Confirmation prompt should be displayed:

----------------------------------------------------------------------------------------------------------------------------------------------

Note that I’ve noticed there are times when the wizard would prompt all of the disks at the same time rather than prompting for each individual disks as shown above:

----------------------------------------------------------------------------------------------------------------------------------------------

Configure the Quiescing method as previously documented:

Configure the Recovery settings as previously documented and complete the configuration by clicking Finish::

The replicated virtual machine should now be displayed again with an Initial Full SyncStatus:

Clicking on the i icon in the GUI would provide information:

To obtain more information on the status of the synchronization, log onto the esxi host with the protected VM is inventoried and execute:

vim-cmd vmsvc/getallvms

... to list all the VMs along with their Vmid:

Note the Vmid and execute the command:

vim-cmd hbrsvc/vmreplica.getState <Vmid>

This will display an output similar to the following:

I usually periodically execute the vim-cmd hbrsvc/vmreplica.getState command to check the progress as it provides more information:

The time it takes for the process to complete will vary depending on the size of the virtual machine but note that only changes are replicated over and not the full virtual machine.  The following are some screenshots taken during the synchronization:

After the required time, the virtual machine should get back to an OK Status as such:

Hope this would help anyone looking for what the full process of expanding a replicated virtual machine’s hard disk would look like.

Problem

You attempt to launch a Citrix XenApp / XenDesktop 7.x application published with a NetScaler VPX:

The following Citrix Receiver Remote Desktop Connection window is presented and displays the progress bar:

Starting…

More information

Clicking on the More information button displays:

Connection in progress…

Less information

The progress bar does not proceed any further and the process eventually fails with the message:

Unable to launch your application. Contact your help desk with the following information:

Cannot connect to the Citrix XenApp server. Network issues are preventing your connection. Please try again. If the problem persists, please call your help desk.

Attempting to launch the XenApp desktop displays the launch window:

… but will fail with:

The connection to “XenApp Weir Desktop” failed with status (Unknown client error 1110).

Solution

While there could be several reasons why this error would be thrown, one of the possible causes is if the Citrix session reliability port 2598 is blocked from NetScaler to application server.  Ensure that the NetScaler can access the XenApp server via TCP port 2598.

I’ve recently had to migrate a client from Exchange 2010 to 2016 and quickly noticed that Outlook Anywhere no longer worked after redirecting Outlook Anywhere and other services such as autodiscover and webmail to the new server.  Outlook Anywhere continued to work for users migrated to Exchange 2016 but not for users still on the legacy Exchange server.  Using the Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) Outlook Connectivity feature would fail and throw the following error:

I was unable to find an official Microsoft KB which described this issue but I was able to come across this blog post for migrating from Exchange 2007 to Exchange 2013:

Exchange 2013 to 2007 Outlook Anywhere Proxy Issue
https://smtp4it.net/2013/12/05/exchange-2013-to-2007-outlook-anywhere-proxy-issue/

… and I can confirm that after adding the registry keys onto the Exchange 2010 servers as such:

… then restarting the servers was able to correct the Outlook Anywhere problem for Exchange 2010 users during the Exchange 2016 migration:

I’ve noticed that many of my colleagues and clients have asked me about the following error that is thrown when they attempt to export an Exchange Server mailbox to PST so I thought it would be a good idea to quickly write a post about the error.

Problem

You attempt to export a mailbox to PST via the Exchange Admin Center but received the following error:

Couldn’t locate a database suitable for storing this request.

Using the New-MailboxExportRequest feature displays a similar error:

[PS] C:\Windows\system32>New-MailboxExportRequest -Mailbox mbraithwaite -FilePath "\\tmrfp09\archive$\Outlook Archive\mb
raithwaite.pst"
Couldn't locate a database suitable for storing this request.
     + CategoryInfo          : InvalidArgument: (mbraithwaite:MailboxOrMailUserIdParameter) [New-MailboxExportRequest],
     MailboxDatabase...manentException
     + FullyQualifiedErrorId : [Server=contBMEXMB01,RequestId=c7446094-7d17-4e06-90c4-07be8ca10829,TimeStamp=8/23/2017 2
    :46:00 PM] [FailureCategory=Cmdlet-MailboxDatabaseVersionUnsupportedPermanentException] 4B192EAA,Microsoft.Exchang
   e.Management.Migration.MailboxReplication.MailboxExportRequest.NewMailboxExportRequest
     + PSComputerName        : contbmexmb01.contoso.com

[PS] C:\Windows\system32>

Solution

The reason why this error would be thrown is if you are trying to export a mailbox that is on a different version than the admin console you are working from.  In the example above, the attempt was made from the Exchange 2016 admin center but the mailbox actually resides on an Exchange 2010 server.  Simply execute the export job from the PowerShell prompt of one of the Exchange 2010 servers to get the mailbox to export.

Problem

You have two Exchange 2016 mailbox servers configured as a DAG and one server providing witness servers.  One of the mailbox server experiences an issue and goes down so the remaining mailbox server continues to service mailbox requests and has the databases mounted.  The remaining operational server is restarted and you immediately notice that the databases are not mounted after the restart: 

Attempting to mount the databases with the Mount-Database command throws the following error:

[PS] C:\Windows\system32>Mount-Database contoso-edb16-01

Failed to mount database "contoso-edb16-01". Error: An Active Manager operation failed. Error: An Active Manager operation

encountered an error. To perform this operation, the server must be a member of a database availability group, and the

database availability group must have quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does

not allow auto mount. (IsAllNodesUp: False)). [Server: contoso-MBX16-01.contoso.NET]

    + CategoryInfo          : InvalidOperation: (contoso-EDB16-01:ADObjectId) [Mount-Database], InvalidOperationException

    + FullyQualifiedErrorId : [Server=contoso-MBX16-01,RequestId=ae45aaee-8113-4908-a0fd-34e3d4a032a2,TimeStamp=17/08/2017

    12:20:16] [FailureCategory=Cmdlet-InvalidOperationException] A5CACA44,Microsoft.Exchange.Management.SystemConfigu

  rationTasks.MountDatabase

    + PSComputerName        : contoso-mbx16-01.contoso.net

[PS] C:\Windows\system32>Get-DatabaseAvailabilityGroup

Executing the Get-DatabaseAvailabilityGroup cmdlet displays the following message:

Warning: Unable to get Primary Active Manager information due to an Active Manager call failure. Error: An Active Manager operation failed. Error: An Active Manager operation encountered and error. To perform this operation, the server must be a member of a database availability group, and the database availability group must have a quorum. Error: Automount consensus not reached (Reason: ConcensusUnanimity does not allow auto mount. (IsAllNodesUp: False)).

Executing the Get-MailboxDatabaseCopyStatus * cmdlet indicates the status of the mailbox databases in the DAG as Unknown:

Solution

The reason why the databases would not automount and manually mounting them would fail is because the DAG has Datacenter Activation Coordination (DAC) mode enabled and this forces starting DAG members to acquire permission in order to mount any mailbox databases.  In the example above, the DAG is unable to achieve a quorum with the second node down and therefore the DAG isn’t started and databases would not be able to mount.  If you are sure that the second node is down as in the example above, you can manually start the DAG with the cmdlet:

Start-DatabaseAvailabilityGroup -Identity <DAG NAME> -MailboxServer <MailboxServerName>

The status of the mailbox databases should now be listed from Unknown to Dismounted once the DAG has been started and issuing the Mount-Database cmdlet will now successfully mount the databases:

The following are TechNet blog posts that provide a more in depth explanation of DAG and DAC:

Part 1: My databases do not automatically mount after I enabled Datacenter Activation Coordination
https://blogs.technet.microsoft.com/timmcmic/2012/05/21/part-1-my-databases-do-not-automatically-mount-after-i-enabled-datacenter-activation-coordination/

Part 5: Datacenter Activation Coordination: How do I force automount consensus?
https://blogs.technet.microsoft.com/timmcmic/2013/01/27/part-5-datacenter-activation-coordination-how-do-i-force-automount-consensus/

Those who have used my previous blog post:

Securing Citrix NetScaler VPX to score A+ rating on SSL Labs
http://terenceluk.blogspot.com/2016/06/securing-citrix-netscaler-vpx-to-score.html

… to score an A+ on Qualys SSL Labs (https://www.ssllabs.com/ssltest/) may have noticed that they are now scoring an A- due to some minor changes to the criteria. 

There is no support for secure renegotiation. Grade reduced to A-. MORE INFO »

The server does not support Forward Secrecy with the reference browsers. Grade reduced to A-. MORE INFO »

The required changes to the configuration are minimal so this blog post serves to demonstrate the tweaks required to bring the score back to an A+.

The version of the NetScaler VPX I’ll be using for this demonstration is:

NS11.1: Build 49.16.nc

Step #1 – Confirm that the SSL certificate used is SHA2/SHA256 signature

Ensure that the SSL certificate used to secure the site uses the SHA2/SHA256 signature for both the root and intermediate.

Step #2 – Confirm that SSVLv3 is disabled and TLSv12 is enabled

With the appropriate certificate assigned begin by ensuring that SSLv3 is disabled and TLSv12 is enabled for the SSL Parameters of the virtual server:

Step #3 – Update Custom Ciphers

The ciphers listed in my previous post is outdated so proceed to remove the existing configuration or appending the new ciphers in, or creating a new one with the following ciphers:

TLS1.2-ECDHE-RSA-AES256-GCM-SHA384
TLS1.2-ECDHE-RSA-AES128-GCM-SHA256
TLS1.2-ECDHE-RSA-AES-256-SHA384
TLS1.2-ECDHE-RSA-AES-128-SHA256
TLS1-ECDHE-RSA-AES256-SHA
TLS1-ECDHE-RSA-AES128-SHA
TLS1.2-DHE-RSA-AES256-GCM-SHA384
TLS1.2-DHE-RSA-AES128-GCM-SHA256
TLS1-DHE-RSA-AES-256-CBC-SHA
TLS1-DHE-RSA-AES-128-CBC-SHA
TLS1-AES-256-CBC-SHA
TLS1-AES-128-CBC-SHA
SSL3-DES-CBC3-SHA

The following command can be used to create a new custom cipher with the required ciphers:

add ssl cipher Custom-VPX-Cipher

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-256-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-ECDHE-RSA-AES-128-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES256-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-ECDHE-RSA-AES128-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES256-GCM-SHA384

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1.2-DHE-RSA-AES128-GCM-SHA256

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-DHE-RSA-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-256-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName TLS1-AES-128-CBC-SHA

bind ssl cipher Custom-VPX-Cipher -cipherName SSL3-DES-CBC3-SHA

With the custom cipher created, ensure that the virtual server is configured to use it:

Step #4 – Configure Deny SSL Renegotiation to FRONTEND_CLIENT

Navigate to Traffic Management > SSL > Change advanced SSL settings:

Change the Deny SSL Renegotiation setting from ALL to FRONTEND_CLIENT:

Alternatively, the following command can be executed to change the configuration:

set ssl parameter -denySSLReneg FRONTEND_CLIENT

-------------------------------------------------------------------------------------------------------------------------

You should now score an A+ with the adjustments listed above configured:

Remember to save the configuration!

Problem

You’ve recently had to reset the password to the SQL authentication account used by your VMware vCenter Site Recovery Manager to connect to the SRM database so you proceed to update the ODBC System DSN as such:

However, attempting to start the VMware vCenter Site Recovery Manager service fails with the following error:

The VMware vCenter Site Recovery Manager Server service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.

The following event error is logged in the event logs after the failed start:

Log Name: Application

Source: vmware-dr

Event ID: 3

Level: Error

DBManager error: Could not initialize Vdb connection: ODBC error: (28000) - [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'vmware'.

Attempting to modify the installation of SRM will display the following error:

A database error has occurred.

Solution

The reason why the service is unable to start is because other than updating the ODBC System DSN, you’ll also need to use one of the steps in the following KB to update the password:

Migrating an SRM server to run on a different host (1008426)
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008426

The step required to get the environment in this example up is #7:

Run the installcreds.exe utility to register account credentials on the new host with the old DSN:
installcreds.exe -key db:new_SRM_DSN -u sql_admin_user
The installcreds.exe utility can be found in the bin directory of the SRM installation:
C:\Program Files\VMware\VMware Site Recovery Manager\bin

The following is an example of the executed command:

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>installcreds.exe -key db:SRMDR -u vmware
VMware internal use only. This program is intended for use only by the SRM installer.
Enter Password:
Installed new credentials for db:SRMDR

C:\Program Files\VMware\VMware vCenter Site Recovery Manager\bin>

The service should now start as the password has been updated:

Problem

You’ve created a new certificate for your Lync Server 2013 services and attempt to assign it to Server default and Web services internal:

However, the assignment fails and the following error message is displayed:

Command execution failed: The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.

Solution

One of the reasons why the certificate assignment would fail with the error message above is if an administrator or group policy has removed the administrators group from the Lync Server’s Manage auditing and security log policy as shown in the following screenshot:

To correct the problem, simply grant the local administrators group the Manage auditing and security log policy permissions:

You should be able to assign certificates to Lync Server 2013 services once the above has been completed.

Problem

You’ve completed the process of creating a new keystore with a CSR from the Portecle utility:

http://portecle.sourceforge.net/

Since the Portecle utility does not provide the feature to include SAN entries:

https://www.sslsupportdesk.com/portecle-advanced-keystore-creation-and-manipulation-tool/

This isn’t usually a problem because it is possible to add SAN entries in the Additional Attributes field when submitting the CSR to a Microsoft Certificate Authority server as described here:

How to add a subject alternative name to a secure LDAP certificate
https://support.microsoft.com/en-us/help/931351/how-to-add-a-subject-alternative-name-to-a-secure-ldap-certificate

An example of the format of the string to include is:

san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com

You proceed to submit the request:

… but notice that the generated certificate does not include a SAN entry.

Solution

One of the reasons why performing the above would not generate a certificate that includes a SAN entry is if the issuance policy of the Microsoft CA is not configured to accept the Subject Alternative Name(s) attribute via the CA Web enrollment page.  To correct this, execute the following command:

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

Once the above command is executed, stop and start the certificate authority with:

net stop certsvc
net start certsvc

Proceed to use the CA web enrollment page to generate the certificate with the SAN entry.

---------------------------------------------------------------------------------------------------------------------------

Security Concerns:

Note that as per the following Microsoft article:

https://technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx

It is not recommended to enable the acceptance of the SAN attribute for the CA Web enrollment page so please review the Security best practices for allowing SANs in certificates section in the article above to be aware of the security concerns.

Problem

You’ve started the installation of Exchange Server 2016 Cumulative Update 7 but notice that it fails at the step Mailbox role: Transport service with the following error:

Error:

The following error was generated when "$error.Clear();

Install-ExchangeCertificate -services IIS -DomainController $RoleDomainController

if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)

{

Install-AuthCertificate -DomainController $RoleDomainController

}

" was run: "System.Security.Cryptography.CryptographicException: The certificate is expired.

at Microsoft.Exchange.Configuration.Task.Task.ThrowError(Exception exception, ErrorCatagory errorCatagory, Object target,

String helpUrl)

at Microsoft.Exchange.Management.SystemConfigurationTasks.InstallExchangeCertificate.InternalProcessRecord()

at Microsoft.Exchange.Configuration.Tasks.Task.<ProcessRecrod>b_91_1()

at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolen

terminatePipelinelfFailed)”.

Solution

The reason why the installation of the CU update failed is because the process attempts to validate the certificate Exchange Server 2016 is using for its services and if an expired certificate is found to be binded to a service, the update will fail.  What usually causes panic at this point is that the Exchange server services are not going to be up and trying to launch the Management Shell would prompting show that Exchange PowerShell cmdlets are not available:

To get through this issue, you can simply assign a valid certificate via the Internet Information Services (IIS) Manager console:

Note that the screenshot above has the binding configured with the self-signed certificate generated by the initial Exchange 2016 installation.  Using the self-signed certificate is a good way to workaround not being able to proceed with the CU install while you renew the certificate.

With the certificate bindings configured with a valid certificate, proceed to rerun the CU update and it should complete as expected:

I recently ran into a strange issue with a client that had a satellite office with 4 users who use a Lenovo Windows 10 PC and VMware Horizon View client to connect back to their desktops in the main datacenter.  The satellite office is relatively new so the VMware Horizon View client installed onto the PCs were version 4.5.0 but two of the desktops recently had to be swapped out due to hardware failures and since a newer 4.6.0 client was out, I decided to go with the latest version.  Shortly after the new Lenovo PCs with the newer client were deployed, I received reports that:

1. Attempting to print a multiple paged email from their Outlook 2010 client would insert blank pages in between pages with content and/or skip some pages all together
2. Attempting to print attachments (e.g. PDF) on emails would send the print job but nothing prints
3. Word documents print properly

I originally did not suspect this was related to VMware Horizon View so I sent my colleague out to have her check the drivers and any other Windows components worth reviewing.  A day goes by without a resolution so the issue was escalated to me and that was when I realized the only difference between the two non-working PCs and the other ones that were working was the newer VMware Horizon Client 4.6.0.9732:

Having exhausted most options that could be tried on the Windows 10 operating system, I quickly downgraded the client to 4.5.0.8090 and printing immediately functioning as expected:

I’m not completely sure there is a known bug for this client as the release notes here does not mention such an issue:

VMware Horizon Client 4.6 for Windows Release Notes
https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/4.6/rn/horizon-client-windows-46-release-notes.html

I hope this blog post will be able to help anyone who may come across this issue and in case anyone wants to compare operating version versions, below is the Windows OS on the Lenovo details:

Problem

You’ve noticed that backup jobs within VDP have been failing with the following errors:

VDP: An attempt made to backup a client failed because no data was found that matches the type of data that the job was configured for.

VDP: An unexpected error occurred with the following error code: 30983. More information may be available in the client logs which can be downloaded from the configuration application (https://<VDP hostname>:8543/VDP-configure).

Viewing the task failure report displays the following:

Reason: VDP: An attempt made to backup a client failed because no data was found that matches the type of data that the job was configured for.

Log file retrieved is empty.

Reason: VDP: An unexpected error occurred with the following error code: 30983. More information may be available in the client logs which can be downloaded from the configuration application (https://<VDP hostname>:8543/VDP-configure).

Failed to retrieve log file. This can happen if:

* Management Services were recently restarted.

* Regular log maintenance has removed old log files.

* Logs may be empty or non existent.

*An error may have occurred.

Solution

One of the reasons why the VDP backup jobs have failed and will continue to fail is if you have a mismatch between supported versions of VDP with the vCenter version that you are running.  In the example above, the failures started when the vCenter server was upgraded to:

Version: vCenter Server 5.5 Update 3e

Release Date: 2016-08-04

Build Number: 4180647

Installer Build Number: 4180646

The VDP appliance in the environment was at version 6.1.2.19:

The supported version for vCenter Server 5.5. Update 3e was 6.1.3 so updating the VDP appliance to 6.1.3.70 corrected the problem:

Problem

You would like to migrate Exchange 2016 resource mailboxes from one database to another but noticed that the Move Mailbox To another database is not available when you select the resource mailbox:

Shared mailboxes does not have this issue:

Solution

I’m not sure if this is by design but to move the resource mailboxes to another database via the Exchange admin center, use the migration option as such:

Using this wizard will allow you to select the resource mailboxes:

Problem

You attempt to run Windows updates on a Windows 7 desktop but notice that it fails with the following message:

Windows could not search for new updates

An error occurred while checking for new updates for your computer.

Error(s) found:

Code 80248015

Windows Update encountered an unknown error.

Solution

One of the ways to correct this issue is to navigate to the Windows directory and rename the SoftwareDistribution folder so that it would get recreated. 

C:\Windows\SoftwareDistribution

Restart the desktop once the folder has been renamed and Windows update should now work as expected: