I have created a rule in Exchange Admin Server (EAC) that forwards a specific message for approval, to the admin.
The problem is when the message match the rule, it needs to go to an offline server which had a Discovery Database (I don't know if because it has this Discovey Database). I can see it in the "Queue Viewer" blocked trying to connect to the ip of this offline server..
But when I change the rule to onlu forward the message (without approval) to the admin, it works.
Related
We have a web application written using Liferay 6.2 and deployed on tomcat server. Application is accessed using Integrated Windows Authentication. Everything works fine if hostname is directly used to in url to access.
To hide the actual hostname, a CNAME record was created. When that is used to access, users get repeated prompts for credentials and authentication is rejected despite entering correct credentials.
We tried creating SPN for CNAME using the command setspn -a "HTTP/<<friendly name>>". Since connection is made on standard port 443 using HTTPS, no port number was specified when creating SPN. However, repeated authentication prompts still continue to appear. The application runs using a service account. Including the service account when creating SPN could be an option. Please share if there are any suggestions on what else could be tried.
What does "everything works fine" mean? Are you getting prompted and when you enter creds it works correctly, or it does SSO and logs you in without a prompt?
The fact that you're getting prompted is because a) the new cname isn't considered to be in the intranet/trusted internet zone. See Internet Options > Security > Local Intranet/Trusted Sites > Sites. Or b) the requested ticket sent to the server failed.
Also usually you don't register the cname as an SPN. You register the A record the cname is pointing to as the SPN. My guess is this is causing the failure. The SPN is getting registered to the wrong service account so the KDC is using the wrong service account key.
I have configured my sharepoint server for outgoing email. I used this tutorial
https://manojviduranga.wordpress.com/tag/configure-sharepoint-outgoing-email-step-by-step/
also tried this one:
https://technet.microsoft.com/en-us/library/cc288949(v=office.14).aspx#section5
to test if it's working, I created a simple list workflow to send email everytime a new item is created. when I create a new item in the list, the workflow progress is "Complete" but the email is not sent and there's a workflow error "The e-mail message cannot be sent. Make sure the outgoing e-mail settings for the server are configured correctly."
I check all possible solutions I could find. checked the anti-virus, tried adding a pause in the workflow, restarted server and iis. I kept getting the same workflow error.
is there any other solution that could fix this problem?
First you need to be certain that Sharepoint can send emails. To do that just go to your list and in the top menu choose List and then "Alert me". Now set to receive new alerts on newly created items.
Now create new item and check if you received email. If not - your sharepoint or SMTP server is misconfigured.
You can diagnose your SMTP server by opening telnet client (start->run->cmd-> type "telnet").
in telnet client write:
open yoursmtpserveraddress:25
helo test
mail from:anyone#yourdomain.com
rcpt to:your_email#yourdomain.com
data
.
If this will succeed without errors, then your SMTP server is working. Then you should check Sharepoint configuration. Otherwise reconfigure your smtp server and/or firewall.
We are hosting email with a hosted exchange provider so it is separate from the website.
The domain is registered with 123 reg and the nameservers are pointing to a server where the web files and database sit. From our control panel we have configured the appropriate MX/DNS entries to point the email to the hosted exchange server.
If our server went down where our website sits, will our email go down too because the MX records and DNS entries are hosted on this server?
Thanks
It depends. DNS is usually cached, so any email server that recently sent you a message and the TTL hasn't expired, should be able to reach you. Any new requests could go unanswered.
That being said, what I described will not provide any reliable redundancy. The best solution is to have another authoritative dns server in a separate location in case your server goes down.
It sounds like you're worried about missing messages. If your downtime isn't more than 24 hours you should be ok. Most email servers will try several times to send a message before it's returned.
I'll try to be clearest as possible as I think this is not a usual situation. If you need more details, please say it.
I work on a company that has an Exchange Server. They provide a laptop which is on company domain and I can connect in Outlook just fine with my company e-mail. If I go home with my company laptop I can connect via VPN to company domain and connect to Outlook just fine as well.
We have a webmail which we can use in ANY untrusted computer on browser, something like webmail.mycompany.com and I just need to put my username and password to connect.
I also have an Android smartphone which is not on domain as well and I can configure it to connect to my company Exchange mail.
However I work on a remote server which is not on company domain (I can't change the domain on the remote server) and I'm trying to configure Outlook on the remote server unsuccessfully...
I'm very confused and wondering:
If I can connect via VPN to my company Exchange mail on Outlook anywhere as long as I have internet access on my company laptop
I can connect to my company Exchange mail on a webmail on browser on any computer (not on company domain) providing username and password.
I can connect to my company Exchange mail on my Android smartphone (not on company domain) by providing the Exchange mail server, username, domain and password.
Question: Is it possible to connect to Outlook in a different domain on a remote server with the information I have?
Thank you!
If an Exchange server is published correctly with ActiveSync enabled, then an device that supports ActiveSync should be able to connect to it. I am contracted out to 4 partner organisations during the week, 1 orgs email is Exchange Online, the others are local exchanges, one each of 2007, 2010, 2013.
I can easily hook up my email accounts to each of these from my phones, outlook 2010 at home (not connected to the domain or VPN) and outlook 2013 in the office (that is domain connected). (For 2 of these orgs my first job was to correctly publish their exchange farm for their employees)
You mentioned a VPN tunnel, if you have to establish a VPN to connect to the exchange then it sounds like it has not been correctly published externally, possibly by design.
The first thing you should do is talk to your Exchange Admin and ask them to confirm or publish the Autodiscover and ActiveSync related services for the exchange you wish to connect to externally, it's quite secure by default and has been designed to be used in this way so you shouldn't get much resistance on this front.
If you are the admin, or just playing along at home, then your next stop should be the Microsoft Connectivity Analyzer https://testconnectivity.microsoft.com , previously testexchangeconnectivity.com... that uses the same protocols that outlook and mobile devices use to connect to MS Exchange, this includes Exchange Online.
If the connectivity analyzer can connect, but your client can't then download the client analyzer from the "client" tab in the connectivity analyzer site. The error prompts are really informative and help to improve your understanding of how the Exchange platform works
Outlook 2010 can only add one domain connected Exchange service at a time, but it can have many activeSync compatible services connected no worries at all. Follow the test results on the connectivity analyzer site described above for guidance, the two most common issues that I come across are:
You primary email alias may not match the autodiscover service. For instance user#email.com might belong to an exchange that is published as 'electronicemail.com' In this case you need to make sure you connect to the exchange service as 'user#electronicemail.com' your default replay to address as configured in exchange will still work as user#email.com, but outlook doesn't know about these details untile after it has established a connection to the exchange server via the autodiscover service.
The other common issue is that the autodiscover service is not contactable externally or does not resolve correctly when you are external. (this happens a lot with Small Business Server and Essential Business server) In these cases you can sometimes make some quick edits to your c:\windows\system32\drivers\etc\hosts file to direct outlook to the right server IPaddress to configure the account. If you add a hosts entry for autodiscover.yourEmailDomainName.whateveritis into your hosts file this can often get around issues caused by the organisations public DNS not being configured for exchange.
Note that the hosts solution above can work in many instances for both of these issues
Weird question here. Could a mail server be blocking a domain?
I ask because i am in the process of migrating to a new server and i am testing out a few email accounts.
the domain x.com is hosted on server 1
the domain y.com is hosted on server 2
the domain z.com is hosted on server 2
If i email from x.com to y.com, the server replies with
550 sorry, no mailbox here by that name. (#5.7.17)
However, if i send from x.com to x.com also x.com to z.com they send fine.
y.com and z.com are on the server, so i don't see an issue with an IP block or anything like that.
Generally this error happens when mail was hosted on the server at some point, but has since been moved to an external mail server. Qmail will still try to deliver the message locally and fail with this error:
This_address_no_longer_accepts_mail
To correct this check the following two files for the domain in question:
/var/qmail/control/rcpthosts
/var/qmail/control/virtualdomains
Remove the line with this domain from both files then restart Qmail:
/etc/init.d/qmail restart
From http://toastergremlin.com/?p=181