Coming to the next CUs for Exchange 2013 and Exchange 2016 there are some changes to how the Exchange Management Shell (EMS) connects to Exchange. In previous versions, we have seen that customers who were reliant on a load balanced solutions for third party apps and scripts may get routed to a non-Exchange 2016 server. This would lead customers to some broken administrative experiences based on the reliance of Exchange 2016 cmdlets and features. Today we will dive deeper into these changes to help the Exchange Administrator understand how these changes will affect their Exchange Organization.
Check out the full article at The Exchange Team Blog
When installing Exchange 2013 from PowerShell in my lab I ran into an issue and the server failed installing the Client Access Role.
Welcome to Microsoft Exchange Server 2013 Service Pack 1 Unattended Setup
File copy complete. Setup will now collect additional information needed for installation.
Mailbox role: Transport service
Mailbox role: Client Access service
Mailbox role: Unified Messaging service
Mailbox role: Mailbox service
Client Access role: Front End Transport service
Client Access role: Client Access Front End service
Performing Microsoft Exchange Server Prerequisite Check
Configuring Prerequisites COMPLETED
Prerequisite Analysis COMPLETED
Configuring Microsoft Exchange Server
Preparing Setup COMPLETED
Stopping Services COMPLETED
Copying Exchange Files COMPLETED
Language Files COMPLETED
Restoring Services COMPLETED
Language Configuration COMPLETED
Exchange Management Tools COMPLETED
Mailbox role: Transport service COMPLETED
Mailbox role: Client Access service FAILED
The following error was generated when “$error.Clear();
Install-ExchangeCertificate -WebSiteName “Exchange Back End” -services “IIS, POP, IMAP” -DomainController $RoleDomainController -InstallInTrustedRootCAIfSelfSigned $true
if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
Install-AuthCertificate -DomainController $RoleDomainController
” was run: “Could not grant Network Service access to the certificate with thumbprint 1C5101B4BE0AF6CBD6A39FD413436E2649B0124 because a cryptographic exception was thrown.”.
The Exchange Server setup operation didn’t complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.
Since I was already in PowerShell I went ahead and added the Exchange SnapIn since the Exchange Management Tools were installed and checked for the thumbprint listed above
PS C:\Exchange\Setup> Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
PS C:\Exchange\Setup> Get-ExchangeCertificate
Thumbprint Services Subject
———- ——– ——-
4DEAE2C0FD7657546E5BE9C326DFD463F6F3AB3D ….S.. CN=ex02
59A4489083B12076D397B30B27B53397194A2B2C ….S.. CN=Microsoft Exchange Server Auth Certificate
046880AF472664A815FFBC2252860A2E2111231B ……. CN=WMSvc-EX02
As we can see it’s not listed so I decided to look at all the certificates loaded on the server.
I then opened up MMC and added certificates for the local computer and see 4 certificates, however Exchange is only seeing 3. I am not sure where the certificate for the FQDN came from since the labs was just built today (8-10-14). The other three were supposed to be there after an Exchange Server install.
I backed up the certificate and removed it and then re-ran the installation and it resolved the issue.
Unknown at this time. I have been able to reproduce the issue but I do not know why the certificate is there (possible lab image issue). Time to try to debug the issue. J
Sometimes there arises a scenario where you may want to disable remote PowerShell access for your users in Office 365. The main reason for doing so would be to prevent rogue admins, users, or even compromised user accounts from being able to do anything malicious with your tenant.
By default, all users will have remote PowerShell access to your Office 365 Organization. Now RBAC Policies prevent them from doing a whole lot (if they are non-administrative users). However if an account gets compromised there could be issues.
The cmdlet below turns off remote PowerShell for a particular user. You can use this to disable PowerShell for all user’s but remember to do not include the Administrators account or you will not be able to run the Hybrid Configuration Wizard or do any management to the Office 365 Tenant that would require you to use PowerShell and make for a very bad day.
Set-User -Identity <ALIAS> -RemotePowerShellEnabled:$False
If you’re like me I have to play with a lot of labs. I often use the same domain names to make my certificate life a little easier to manage. Maybe you just need to import certificates on a lot of servers. Either case this little snippet will make your certificate life a little easier :-).
Welcome to the Exchange Management Shell!
VERBOSE: Connecting to Exchange Server.
VERBOSE: Connected to Exchange Server.
[PS] C:\PowerShell>$pfxpath = “C:\Certificates\contoso.com.pfx”
[PS] C:\PowerShell>$password = “MyPasswordIsSecure”
[PS] C:\PowerShell>Add-Type -AssemblyName System.Security
[PS] C:\PowerShell>$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2Collection
[PS] C:\PowerShell>$cert.Import($pfxpath, $password, ‘Exportable’)
The Update-DatabaseSchema cmdlet is designed to safely upgrade database schema in a DAG deployment. Unlike previous releases, a database schema upgrade in Exchange 2013 can only occur after all DAG members are upgraded to a version of software that supports the schema version and there is control over when the schema upgrade occurs. This design prevents issues like those encountered during upgrades of Exchange 2010 DAG members that automatically upgraded the database schema version when mounting database on an upgraded server and prevented you from being able to mount the database on a server that has not yet been upgraded.
More Reading: Microsoft Exchange Team Blog
Cmdlet Information: Update-DatabaseSchema