Tech Room

exchange 2013 Transport service stuck at starting

admin — Mon, 04 Jun 2018 19:48:20 +0000

the problem should be the queue database. If you stop the ExchangeTransport Service, delete or rename the queue database and then restart the Transport Service, the issue could be resolved. Please follow the steps below: 1). Stop Msexchange transport service manually on it. 2). Go to path below: c:\program files\Microsoft\Exchange Server\TransportRoles\Data\Queue on mailbox server.(by default … Continue reading

Disable Hibernate in windows 10

admin — Sun, 18 Feb 2018 13:42:35 +0000

enable or disable Hibernate in Windows 10

Press Windows + X keys to open Power menu and select Command Prompt (Admin)
To enable the Hibernate, type command powercfg/h on.
To disable the Hibernate, type command powercfg/h off.
Go to Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Power. Double click on HibernateEnabled. 1 is enabled 0 is disabled

Restoring an Exchange Server 2013 Database

admin — Fri, 30 Jun 2017 17:50:10 +0000

In a previous article I demonstrated how to restore Exchange Server 2013 databases using Windows Server Backup. In that scenario an entire database that had been lost needed to be recovered.

However in other recovery scenarios you may only want to recover one or several mailboxes, or even specific mailbox items, from a point in time without having to overwrite the entire database.

In Exchange Server 2013 we can do this with recovery databases, which operate basically the same as Exchange Server 2010 recovery databases. A recovery database allows us to mount a copy of a database on an Exchange server without having any impact on the live copy of that same database. In fact we can even use recovery databases to mount copies of databases from other servers within the same Exchange organization, thanks to database portability.

When a recovery database is mounted we can inspect it and restore items or mailboxes from it, but no clients can connect to it. So as the name suggests it can only be used for recovery purposes, not for active mailbox functionality.

Restoring an Exchange Server 2013 Database Using Windows Server Backup

Some backup applications have the capability to handle some or all of the process of creating a recovery database, restoring the database files, and extracting the desired mailboxes or items to a destination.

When using Windows Server Backup to perform a recovery you need to do pretty much all of the work yourself, so it is a good exercise for learning how to recovery Exchange 2013 databases.

In Windows Server Backup click Recover to start a new recovery.

Choose the location where the backup is stored. In this example my backups are stored on the same server.

Choose the backup date and time that you wish to restore.

When recovering entire databases we would normally choose “Applications” and restore every database that was backed up on the server. However when working with recovery databases we can chooseFiles and folders and only restore the specific database and log files we need.

Browse through the tree of available items and choose the database and log files you want to restore. I am restoring DB02 in this example. Note that restoring the database and logs will be two separate restore jobs if they are located in folders where you can’t select both at the same time.

Choose to restore to Another location, and select a folder that has enough free space to hold the restored data.

Confirm your selections and click Recover to begin the restore.

You can close the progress window if you like and the job will continue running in the background.

I’ve also run a second recovery job to restore the log files for DB02.

After you’ve completed your file restores the next step is making the database mountable.

Making the Restored Database Mountable

So far we’ve restored the database and transaction log files from a recent backup, but haven’t created the actual recovery database yet. If we created the recovery database right now, pointing it at the restored database and log files, and then tried to mount it, the database would fail to mount.

The reason for this is that the restored database is in a “dirty shutdown” state, which you can see by navigating to the restored database folder and running eseutil.exe.

1
2
3
4
5
6
7
8
9
10

F:RecoveryDB&gt;eseutil /mh DB02.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
         Database: DB02.edb
            State: Dirty Shutdown

I have abbreviated the output of the above command, but basically you are looking for the “State” shown in the command output.

So we need to get the database file to a “clean shutdown” state before it can be mounted.

In my example I have:

A database file named DB02.edb in F:RecoveryDB
Transaction logs with the filename prefix E01 in F:RecoveryLogs

So my eseutil “soft recovery” command line will be:

1

F:RecoveryDB&gt;eseutil /r E01 /l F:RecoveryLogs /d F:RecoveryDB

What that command means:

/r for “recovery” mode
E01 for the log file name prefix
/l (lower-case L) to specify the path to the log files
/d to specify the path to the database file (but do not include the name of the file itself)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

F:RecoveryDB&gt;eseutil /r E01 /l F:RecoveryLogs /d F:RecoveryDB
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating RECOVERY mode...
    Logfile base name: E01
            Log files: F:RecoveryLogs
         System files:
   Database Directory: F:RecoveryDB
Performing soft recovery...
                      Restore Status (% complete)
          0    10   20   30   40   50   60   70   80   90  100
          |——|——|——|——|——|——|——|——|——|——|
          ...................................................
Operation completed successfully in 2.359 seconds.

After the command has completed check the state of the database with eseutil /mh again.

1
2
3
4
5
6
7
8
9
10

F:RecoveryDB&gt;eseutil /mh DB02.edb
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.
Initiating FILE DUMP mode...
         Database: DB02.edb
            State: Clean Shutdown

If soft recovery does not bring the database to a clean shutdown state you may consider a hard recovery, which will make the database mountable but risks some data loss in the process.

1

F:RecoveryDB&gt;eseutil /p DB02.edb

When the database is in a clean shutdown state you can create the recovery database.

Creating a Recovery Database in Exchange Server 2013

Creating a recovery database is performed using the New-MailboxDatabase cmdlet with the -Recovery switch. Notice that in this example I am using the same database and log file locations as my restored data.

1
2
3
4
5
6
7
8
9

[PS] C:\>New–MailboxDatabase –Server E15MB1 –Name RecoveryDB –Recovery –EdbFilePath F:RecoveryDBDB02.edb –LogFolderPath F:RecoveryLogs
WARNING: Recovery database ‘RecoveryDB’ was created using existing file F:RecoveryDBDB02.edb. The database must be
brought into a clean shutdown state before it can be mounted.
Name                           Server          Recovery        ReplicationType
——                           ———          ————        ———————–
RecoveryDB                     E15MB1          True            None
WARNING: Please restart the Microsoft Exchange Information Store service on server E15MB1 after adding new mailbox
databases.

For more information about the warning to restart the Information Store service read this article. For a recovery database that you are only mounting for a short period of time an Information Store service restart may not be necessary.

Mount the recovery database.

1

[PS] C:\>Mount–Database RecoveryDB

Working with Recovery Databases

With the recovery database mounted you can use Get-MailboxStatistics to confirm that it contains mailbox database.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[PS] C:\>Get–MailboxStatistics –Database RecoveryDB | ft –auto
DisplayName                                                      ItemCount StorageLimitStatus          LastLogonTime
—————–                                                      ————– —————————          ——————–
SystemMailbox{849e4450–d32d–4a1b–90cf–5d0ca8109884}              239
Administrator                                                    102                           6/02/2014 11:06:56 PM
Discovery Search Mailbox                                         3
Aisha Bhari                                                      14996                          7/02/2014 2:05:18 AM
Alison Lindsay                                                   5848                          7/02/2014 12:04:59 AM
Ambrine Berry                                                    5849                           7/02/2014 1:01:17 AM
Ann Parker                                                       6107                           7/02/2014 1:01:34 AM
Bina Faria                                                       15055                          7/02/2014 2:03:36 AM
...snip...

After you have confirmed that data is available for restore you can begin your mailbox or item recovery.

Export a list of all Email addresses exchange

admin — Wed, 14 Jun 2017 12:09:31 +0000

from Power shell

Get-Recipient | Select Name -ExpandProperty EmailAddresses | Select Name, SmtpAddress | Export-csv c:\temp\AllEmailAddress.csv


Get-Mailbox | Select UserPrincipalName,EmailAddresses | Export-Csv C:\Temp\Addresses.csv

Export E-mail Address List From Exchange 2010

If you need a list of your current user list and primary e-mail addresses for whatever reason, it’s an easy thing to carry out with Exchange 2010. No powershell required!

Step 1 – Open up the Exchange Management Console.

Step 2 – Go to the “Recipient Configuration” and click on “Mailbox” on the left hand section of the screen. Make sure the columns you want are displayed in the middle.

Step 3 – On the right hand section click “Export List”. It will bring up a save file dialog box. It will save it as a tab delimited text file.

Exchange Server 2013 setup fails creating Mailbox role

admin — Tue, 13 Jun 2017 06:35:10 +0000

Exchange Server 2013 setup fails creating Mailbox role

There I was installing Exchange Server 2013 on a brand new Windows 2012 Server. All the pre-reqs went on fine, AD Schema extended, no problems, how simple could it be?

And yet, the setup itself fails!?!? I can’t even begin to understand how a vanilla setups on a clean fresh server could fail.

So, during the setup, it gets to :Step 7 of 14: Mailbox Role: Transport Service” and then fails with

Error:

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

if ( ($server -eq $null) -and ($RoleIsDatacenter -ne $true) )

{

Update-RmsSharedIdentity -ServerName $RoleNetBIOSName

}

” was run: “Database is mandatory on UserMailbox. Property Name: Database”.

Looks like Microsoft *still* haven’t been able to work out how to provide actual useful error messages.

At least it appears to be a known error, and there’s a KB article describing it. Although for Exchange 2010 I figured it should be close enough.
http://support.microsoft.com/kb/978776

So off to ADSIEDIT, delete the user as suggested. I can’t “recreate” the account because the powershell doesn’t work because Exchange isn’t installed yet! Next step is to rerun the Mailbox role setup application… huh? What “application” would that be?

I tried just running the Setup again. It starts, tells me the previous setup failed and that it will try to continue. No choice if I want to either. Once it starts, it then seems to just stop at 0%. There’s no further activity I can detect. Any attempts to start the setup again result in the same, just stopping at 0%

SOLUTION:

So, technically this is partly my bad, however it is a similar problem that might be encountered if someone has an Exchange install fail part-way for whatever reason. In my case it was due to residual objects still being present in Active Directory from a previous Exchange 2010 install. The problem relates to the permissions on those old user objects where the new Exchange server doesn’t have the required permissions due to the old installation “owning” those objects.

So, from here the fix was to Uninstall Exchange 2013 (or what little there actually was of it), reboot the server
In AD Users and Computers, find and delete *all* those old Exchange mailbox type system accounts (Federatedemail, DiscoverySearchMailbox, HealthMailbox, Migration, SystemMailbox, etc.)
Run the Exchange ADPrep again to recreate those accounts. This is instead of the step mentioned in the article to re-create the accounts as the ADPrep will take care of that
Start Exchange setup again and it should complete correctly

totally remove exchange 2016

admin — Mon, 12 Jun 2017 02:37:45 +0000

On the Remove Exchange Server page, you can remove Exchange from the computer.

When you remove Exchange from the computer, the following are removed:

All server roles.
All installation files.

The Exchange server object and all its child objects from Active Directory.

Important:
If you used `Setup.exe /NewProvisionedServer` to provision the server, you must use `Setup.exe /RemoveProvisionedServer` after Exchange has been removed from the computer to remove the Exchange server object and all its child objects from Active Directory.

Removing Exchange from a computer doesn’t remove any Exchange-related databases or log files. You must remove those files manually.

Repairing a virtual disk in Workstation

admin — Thu, 08 Jun 2017 20:42:13 +0000

Linux Host

To repair a virtual disk of a Workstation virtual machine in a Linux host, use the vmware-vdiskmanager utility that is installed by the Workstation installer in the /usr/bin folder on a Linux host.

To use the virtual disk repair utility on a Linux host:

Open a terminal window in the Linux host.
Run this command:
/usr/bin/vmware-vdiskmanager -R

Note: Where is the folder path to the virtual disk that appeared in the error.

Windows Host

To repair a virtual disk of a Workstation virtual machine in a Windows host, use the vmware-vdiskmanager utility that is installed by the Workstation installer in the installation folder on a Windows host.

To use the virtual disk repair utility on a Windows host:

Open a command prompt. For more information, see Opening a command or shell prompt (1003892).
Navigate to the directory where Workstation is installed. By default, this directory is located at:
- Windows XP –C:\Program Files\VMware\VMware Workstation
- Windows Vista/Windows 7/Windows 8 32bit –C:\Program Files\VMware\VMware Workstation
- Windows Vista/Windows 7/Windows 8 64bit –C:\Program Files (x86)\VMware\VMware Workstation
- Windows Server 2008 R2 –C:\Program Files (x86)\VMware\VMware Workstation
- Windows Vista/Windows 7/Windows 8 64bit/Windows 10 – C:\Program Files (x86)\VMware\VMware Workstation
Run the command:
vmware-vdiskmanager -R “”

Note: Where < path of the vmdk(virtual disk> is the complete path to the virtual disk that requires repair as reported in the error.

Example: vmware-vdiskmanager -R “D:\Virtual Machine\Windows 7\virtualdisk.vmdk”

Exchange 2007/2013 CoExistence URLs

admin — Fri, 12 Aug 2016 06:22:47 +0000

Exchange 2007/2013 CoExistence URLs

January 22nd, 2014| Tags:

Introducing Exchange 2013 into an Exchange 2007 environment can be a challenging task. One of the most overlooked, and least documented topics I see is the proper configuration of URLs for Proxy and Redirection.

A good article to start with is Exchange 2013 interoperability with legacy Exchange Versions by Michael Van Horenbeeck. This article points out when Exchange 2013 will proxy connections to 2007 vs. when it will redirect the connection.

Setup:

Exchange 2007

Ex2007.domain.com
Exchange 2007 SP3 RU10
192.168.100.10

Exchange 2013

Ex2013.domain.com
Exchange 2013 RU3
192.168.100.20

In this scenario we have a very simple setup. A single Exchange 2007 server and a single Exchange 2013 server. Both servers are installed in the same Active Directory Site.

Prior to Exchange 2013 being introduced, our 2007 URLs were configured as follows:

Virtual Directory	Current 2007 Values (Prior to Exchange 2013)
OWA	internalURL: https://webmail.domain.com/owaexternalURL: https://webmail.domain.com/owa
ECP	N/A
ActiveSync	internalURL: https://webmail.domain.com/Microsoft-Server-ActiveSync externalURL: https://webmail.domain.com/Microsoft-Server-ActiveSync
Outlook Anywhere	externalHostName: webmail.domain.comIISAuthenticationMethods: BasicClientAuthenticationMethods: Basic
Exchange Web Services	internalURL: https://webmail.domain.com/EWS/Exchange.asmxexternalURL: https://webmail.domain.com/EWS/Exchange.asmx
AutoDiscover	AutoDiscoverServiceInternalURI: https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

…and DNS was configured as follows:

A Record	IP Address
webmail.domain.com	192.168.100.10
autodiscover.domain.com	192.168.100.10

The default internalURL and AutoDiscoverServiceInternalURI values are derived from the server FQDN, but as you can see these have been changed. Your configuration may be different depending on how it was setup.

Likewise, when Exchange 2013 is introduced into the environment, the default values are derived from the server FQDN.

For Coexistence and interoperability between Exchange 2013 and 2007, these values all need to be changed. The first step in the migration process is to update these values so that all users connect to OWA, EAS, and OA via Exchange 2013. Again, I won’t go into the details of why, but essentially Exchange 2013 can proxy and redirect back to 2007, but 2007 cannot proxy forward to Exchange 2013.

“Now, Rabbit, a good cop does what… before using his equipment in the field? – Uh, they test it? – They test it. Exactly. How are you shootin’ today, Thorn? – Dead on all morning. – How about that little fella? Oh, that little guy? I wouldn’t worry about that little guy.”

Yes, I personally like to test everything prior to making any change to the existing 2007 environment. So I usually setup some dummy URLs on the 2013 side and test all the connections (OWA, EAS, OA). This way I know all proxying and redirecting is working prior to making any user impacting changes. This also usually takes some host file manipulation to fully test.

After all testing is complete…it’s time to update the Exchange 2012/2007 URLs. The configurations that we will make should look something like this:

Virtual Directory	2007	2013
OWA	internalURL: https://legacy.domain. com/owa externalURL: https://legacy.domain. com/owa	internalURL: https://webmail.domain.com/owa externalURL: https://webmail.domain.com/owa
ECP	N/A	internalURL: https://webmail.domain.com/ecp externalURL: https://webmail.domain.com/ecp
ActiveSync	internalURL: https://legacy.domain.com/Microsoft- Server-ActiveSync externalURL: $null	internalURL: https://webmail.domain.com/Microsoft-Server-ActiveSync externalURL: https://webmail.domain.com/Microsoft-Server-ActiveSync
Outlook Anywhere	externalHostName: webmail.domain.com IISAuthenticationMethods: Basic,NTML ExternalClientAuthenticationMethods: Basic	externalHostName: webmail.domain.com IISAuthenticationMethods: Basic,NTML ExternalClientAuthenticationMethods: Basic
Exchange Web Services	internalURL: https://legacy.domain.com/EWS/Exchange.asmx externalURL: https://legacy.domain.com/EWS/Exchange.asmx	internalURL: https://webmail.domain.com/EWS/ Exchange.asmx externalURL: https://webmail.domain.com/EWS/ Exchange.asmx
AutoDiscover	AutoDiscoverServiceInternalURI: https://autodiscover.domain.com/ Autodiscover/Autodiscover.xml	AutoDiscoverServiceInternalURI: https://autodiscover.domain.com/ Autodiscover/Autodiscover.xml

…and DNS will look like this:

A Record	IP Address
legacy.domain.com	192.168.100.10
webmail.domain.com	192.168.100.20
autodiscover.domain.com	192.168.100.20

Now, let’s look at some of the configuration.

NOTE: It should go without saying, but the certificate on the Exchange 2007 server should have been replaced by this time with a certificate that contains legacy.domain.com.

OWA – (Redirect) Should be pretty straight forward. When a user whose mailbox still resides on 2007, accesses OWA via the 2013 CAS, they will be redirected back to 2007 via externalURL value: https://legacy.domain.com/owa

Set-OwaVirtualDirectory –Identity “ex2013\owa (Default Web Site)” –InternalUrl https://webmail.domain.com/owa –ExternalURL https://webmail.domain.com/owa

Set-OwaVirtualDirectory –Identity “ex2007\owa (Default Web Site)” –InternalUrl https://legacy.domain.com/owa –ExternalURL https://legacy.domain.com/owa

ActiveSync – (Proxy) I prefer to force ActiveSync to proxy from 2013 to 2007 as some ActiveSync devices don’t handle the redirect correctly. In order to force a proxy scenario, the externalURL value for 2007 is set to $null. The internalURL on 2007 should be configured with https://legacy.domain.com/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2013\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://webmail.domain.com/Microsoft-Server-ActiveSync –ExternalURL https://webmail.domain.com/Microsoft-Server-ActiveSync

Set-ActiveSyncVirtualDirectory –Identity “Ex2007\Microsoft-Server-ActiveSync (Default Web Site)” –InternalURL https://legacy.domain.com/Microsoft-Server-ActiveSync –ExternalURL $null

Outlook Anywhere – (Proxy) All OA connections, both 2007 mailboxes and 2013 mailboxes will now connect via the 2013 CAS. 2013 will proxy connections back to 2007 for legacy mailboxes. The externalHostName for both 2013 and 2007 should be the same, (webmail.domain.com). Exchange 2007 does not support “Negotiate” authentication (See image below). Therefore the externalClientAuthenticationMethods should be configured to match whatever is configured for 2007, either Basic or NTLM. For OA to proxy from 2013 to 2007, the IISAuthenticationMethods on 2007 must be reconfigured to support both Basic and NTLM. By default, Exchange 2007 IISAuthenticationMethods is set to just Basic. NTLM must be added for the proxy to work.

Set-OutlookAnywhere –Identity “Ex2013\Rpc (Default Web Site)” –InternalHostname webmail.domain.com –ExternalHostName webmail.domain.com –ExternalClientAuthenticationMethod Basic –IISAuthenticationMethods Basic,NTLM

Set-OutlookAnywhere –Identity “Ex2007\Rpc (Default Web Site)” –IISAuthenticationMethods Basic,NTLM

Exchange Web Services – (AutoDiscover) Autodiscover is used to retrieve the EWS configuration for the 2007 users.

Set-WebServicesVirtualDirectory –Identity “Ex2013\EWS (Default Web Site)” –InternalURL https://webmail.domain.com/EWS/Exchange.asmx –ExternalURL https://webmail.domain.com/EWS/Exchange.asmx

Set-WebServicesVirtualDirectory –Identity “Ex2007\EWS (Default Web Site)” –InternalURL https://legacy.domain.com/EWS/Exchange.asmx –ExternalURL https://legacy.domain.com/EWS/Exchange.asmx

AutoDiscover – Both the 2007 and 2013 SCP locator can be configured to point to the Autodiscover URL https://autodiscover.domain.com/Autodiscover/Autodiscover.xml. DNS must be updated however so that the A record for Autodiscover.domain.com resolves to the 2013 CAS.

Set-ClientAccessServer –Identity Ex2013 –AutoDiscoverServiceInternalUri https://autodiscover.domain.com/Autodiscover/Autodiscover.xml

ECP – Exchange 2007 did not have an ECP virtual directory. Therefore, only the 2013 ECP virtual directory needs to be configured.

Set-EcpVirtualDirectory –Identity “Ex2013\ecp (Default Web Site)” –InternalURL https://webmail.domain.com/ecp –ExternalURL https://webmail.domain.com/ecp

Troubleshooting AD: Trust Relationship between Workstation and Primary Domain failed

admin — Tue, 05 Jul 2016 01:08:57 +0000

Error message

Error “Trust Relationshitp between Workstation and Primary Domain failed”, is the most encountered message when you are dealing with Active directory domain services.

If the Secure Channel is Broken between Domain controller and workstations

When a Computer account is joined to the domain, Secure Channel password is stored with computer account in domain controller. By default this password will change every 30 days (This is an automatic process, no manual intervention is required). Upon starting the computer, Netlogon attempts to discover a DC for the domain in which its machine account exists. After locating the appropriate DC, the machine account password from the workstation is authenticated against the password on the DC.
If there are problems with system time, DNS configuration or other settings, secure channel’s password between Workstation and DCs may not synchronize with each other.

A common cause of broken secure channel [machine account password] is that the secure channel password held by the domain member does not match that held by the AD. Often, this is caused by performing a Windows System Restore (or reverting to previous backup or snapshot) on the member machine, causing an old (previous) machine account password to be presented to the AD.

Resolution

Most simple resolution would be unjoin/disjoin the computer from the domain and rejoin the computer account back to the domain.
(this is a somewhat similar principle to performing a password reset for a user account)

Or.

You can go ahead and reset the computer account using netdom.exe tool
netdom reset ‘machinename’ /domain:’domainname

Netdom

admin — Tue, 05 Jul 2016 00:49:28 +0000

Commands

Command	Description
Netdom add	Adds a workstation or server account to the domain.
Netdom computername	Manages the primary and alternate names for a computer. This command can safely rename Active Directory domain controllers as well as member servers.
Netdom join	Joins a workstation or member server to a domain. The act of joining a computer to a domain creates an account for the computer on the domain, if it does not already exist.
Netdom move	Moves a workstation or member server to a new domain. The act of moving a computer to a new domain creates an account for the computer on the domain, if it does not already exist.
Netdom query	Queries the domain for information such as membership and trust.
Netdom remove	Removes a workstation or server from the domain.
Netdom movent4bdc	Renames a Windows NT 4.0 backup domain controller to reflect a domain name change. This can assist in Windows NT 4.0 domain renaming efforts.
Netdom renamecomputer	Renames a domain computer and its corresponding domain account. Use this command to rename domain workstations and member servers only. To rename domain controllers, use the netdom computername command.
Netdom reset	Resets the secure connection between a workstation and a domain controller.
Netdom resetpwd	Resets the computer account password for a domain controller.
Netdom trust	Establishes, verifies, or resets a trust relationship between domains.
Netdom verify	Verifies the secure connection between a workstation and a domain controller.