Forum Replies Created
Exchange 2016 is effectively Exchange 2013 SP2. It isn’t the huge leap that there is from Exchange 2010 to 2013.
Saying that, it is too early in its life cycle for wide scale deployment – I have just one site live with 2016. Most new implementations now are cloud based. The way that Microsoft have priced Office365 makes it very difficult to justify the outlay for an on premise implementation.January 27, 2016 at 1:19 pm in reply to: Exchange 2007 Deliver the same email in 3 diffirent user #261535
If the email address is new, then a group.
If the address is on an existing mailbox and you just want a copy to go to others, then a transport rule would work to send it to the other people.
RTM isn’t supported on Windows 2012 R2 – that will be the cause of your problems. The order of prerequisite installation doesn’t matter.
I wouldn’t have even installed SP1, as that is still almost two years old. Try installing CU10 and see if that resolves the issues.
Exactly which version of Exchange 2013 did you install?
Cumulative Updates for Exchange 2013 are the complete product, so you can install a fresh install from any of them. If you aren’t on CU10 already, then I would install that version.
Not that you have missed much in the toolbox – it isn’t like the Exchange 2010 toolbox, it only contains the queue viewer and a few other bits, which you can access from MMC.
There is a reason why you are finding no one with those in production – and that is because they are not well liked by the end users. Open source can do plain email very well, but the collaboration functionality is just not there. Then you have mobile email access. You can use POP/IMAP, but with the associated hit on battery life and data use on the mobile devices – neither of those protocols are designed for mobile use. ActiveSync is licenced by a few, but that will involve cost. Then you have the problem of support – you would have to get trained and finding someone else to support a niche product is going to be difficult.
You mention “your customers” – do you really think it is a good idea to enforce something on to them because you don’t like Microsoft? From a pure business perspective, you are going the quickest way to loosing your customers. If you really want to annoy your end users, why not go the whole way and inflict OpenOffice on them as well!
Are they using Office now? If so, you can effectively get email services for 70p/mailbox/month (UK pricing). The bulk of the Office365 subscription goes to the cost of Office licences.
If you were seeking opinions, you are in the wrong place – this is an Exchange forum. Try Reddit.
The receive connector FQDN should be the server’s real name. Someone has changed it.
Is your MX record mail, rather than remote? If so, switch it to remote, removing the mail.
Then change the FQDN on the receive connector to server.domain.local (ie the server’s real name). That will resolve the errors and will have no effect on mail flow.
Availability comes from the Autodiscover system, so if Autodiscover isn’t working correctly then you can have problems.
Internally Autodiscover is AD site aware, so both locations should have their own URL for Autodiscover. You can see the URL thus:
get-clientaccessserver | select identity, autodiscoverserviceinternaluri
Ensure the host name for the servers in the second site resolves correctly to them and is on the SSL certificate.
ActiveSync does not sync deletions in real time. It is only the incoming that is push. Therefore it can take some time before a deletion is seen by the client, as it has to sync to the mailbox server, then back to the client.November 19, 2015 at 3:13 pm in reply to: Exchange might no be the future, instant messaging could be #261527
I have clients who have actually shutdown their IM because it was too instant. It was having an impact on people’s productivity because they felt they had to deal with the IM there and then. Email allows them to take their time and deal with it later.
The only supported way would be to recover the server and remove it properly.
While you can hack it out using adsiedit, that isn’t supported and it is very easy to cause damage to your live system.
Find the AD computer account, RESET it (not delete).
Build a temporary machine with the same name, then install Exchange 2010 using the recoverserver switch from the command line.
Once it is up, remove the databases (Which will be unmounted) and then remove Exchange using add/remove programs.
Simon.November 17, 2015 at 8:15 am in reply to: Certificate Principal name incorrect for Exchange 2010 #261525
The SSL certificate is issued to a specific name. You cannot change it afterwards because that would allow someone to change their certificate to match your Bank (for example) and pass the SSL requests. If you want the common name changed, then a reissued SSL certificate will be required. You will not be able to get an internal only name on the certificate either. External names only now, which will mean a change to your Exchange server and internal DNS. http://semb.ee/hostnames2010
The external URL for Autodiscover is fixed. You don’t change it in Exchange. That is why it stays at null.
It is either https://autodiscover.example.com/autodiscover/autodiscover.xml or an NSLOOKUP for SRV records or a HTTP redirect from http://autodiscover.example.com – where example.com is the domain after the @ sign in the email address.
The A record would go to the same IP virtual IP address of the CAS role.
Nothing is wrong. That is how it is designed to work.
Email address policy does not remove addresses, only adds them.
Furthermore it is not best practise to change the default policy. Leave the default policy alone and create a new one (or multiple policies if you are applying different addresses).
Simon.November 2, 2015 at 1:17 pm in reply to: Exception OutOfMemory during loading ecp (Exchange 2013) #261521
Not enough RAM. You cannot run Exchange 2013 with less than 12gb of RAM. 2gb is nowhere near enough – even my lab systems have 12gb. It will kind of run at 8gb but that is painful.
This is the official guidance:
I am not aware of a timeframe to resolve the problem other than what it says there. If it is going to be a failing point then you will need to prioritise your upgrade – I would suggest to Exchange 2016 rather than deploying a product that is already over three years old.
You can, whether you should though is another issue altogether.
It isn’t something I would do because the latency would be too high going across the Atlantic.
If you want a copy off site, then use SCR instead. Don’t try and do something like Active/Active over that kind of distance.
Personally I would move to Exchange 2013 or 2016 with two DAGs, one for each location, with a passive located in the other site.
Simon.October 8, 2015 at 7:06 am in reply to: SBS2008 to SBS2008 Exchange Public Folder Replication #261517
Public folder replication is very slow. A week or more of nothing happening isn’t unusual.
The only way to know if something is happening is to look at get-publicfolderstatistics to see whether anything has moved.
You can also look at message tracking to see if the messages are being moved between the servers.
You can force individual folders to replicate in ESM, using the Send Content Now command – but that is a per folder option – if you have a deep tree then it will get tedious quickly.
Simon.September 16, 2015 at 2:31 am in reply to: Microsoft Remote Connectivity test , Outlook Anywhere ( Exch 2007) #261516
If you are using an internal CA then you will never pass the remote tests. End of story.
An internal CA is only suitable for use with Exchange if you have 100% control over all clients accessing the server in any way.
That means all clients – ActiveSync included, and usually means no OWA access.
When you can get a suitable trusted SSL certificate for less than $80/year, it doesn’t make any sense to try and get an internal CA to work.
The certificates generated by Exchange are not supported for use with ActiveSync or Outlook Anywhere.
This is a bad idea on so many counts.
1. The users who receive it will ignore it.
2. or The users who receive it will try and use the new domain before you are ready.
Dealing with a domain name change notification is something that must happen AFTER the event. As part of your migration to Office365 you need to have a plan in place for dealing with email to the old domain. You cannot expect to catch everything automatically – there will be annual emails that are sent to the old domain for example.
The best option is to add the old domain to your Office365 account and add the email addresses to the user accounts. As long as they are not the default email address all new email will go out with the new email domain on them. The use of the old domain will go away over time.
I changed my domain name five years ago – still get legitimate email on the old domain occasionally.
Best practise is quite simple.
1. Change the password on the Administrator account, the lock it away. On some sites I have seen the Administrator account renamed and then disabled. A new account with no privileges called Administrator is created and then the event logs monitored for entries against that account. It can be an early sign of an attack, as the original administrator account cannot be locked out.
2. Create a regular user account for yourself, which is mail enabled. This does NOT have any additional permissions that normal users have. You use this to login to your workstation. If you feel you need to have local admin rights on your workstation, then use that account.
3. Create an admin level account for yourself. This is the account that is granted Domain Admin etc. You use this account to login to the servers. You could use the admin tools on your workstation, but you would need to use Run As. For Exchange 2013 and higher, there is little point installing the admin tools as you don’t get anything. PowerShell connects to the server itself and everything else runs through ECP in a browser.
On older versions, a common trick was to create an admin server. This was a regular Windows server with all of the tools on it, enabled as a RDP (Terminal) server. Admins could then login to that rather than the actual servers to do whatever they needed to do. It meant that the tools only had to be maintained on one server.
Why do you think that isn’t best practise?
You need to be a domain admin to install Exchange for the first time because it makes changes to the domain.
Service Accounts are not required because Exchange uses the built in Service Accounts to run.
Once you have installed Exchange you can set permissions for users, but to install updates will usually require a domain account – particularly service packs/cumulative updates which often have schema updates.
This is a pretty common problem – it will stop the user from using OWA as well.
You need to add the Exchange servers to the list of machines that the end user can login to. Then they will be able to use ActiveSync, OWA etc.
Does the host name that you changed everything to
a. Resolve internally to the Exchange server?
b. Exist on your trusted SSL certificate?
If you don’t have a trusted SSL certificate, then that is the first problem.
You will also need to get your DNS settings corrected.
Outlook Anywhere authentication should be left alone. Basic will always throw an authentication prompt. Negotiate is the usual setting to use.
After making the changes, run IISRESET in an elevated command prompt.