Txt record for exchange organization

Hi,
I am searching on how to get information and how to correctly create txt record in the external DNS to prevent mail spoofing for my accepted domains
currently I have one exchange organization and I have 4 accepted domains which I want to create txt records for them.all I found is related to office 365 not related to hosted Exchange 2013.
I need to et this information to provide it to public dns provider
Mashhour Faraj

Hi,
You can create a TXT record by using DNS Manager on a server running Windows Server 2008 that has the DNS server role installed. Also, you can use the DNSCmd command to create a TXT record.
For more information, here is an article for your reference:
https://technet.microsoft.com/en-us/library/ee423548%28v=exchg.141%29.aspx?f=255&MSPPError=-2147217396
Hope this can be helpful to you.
Best regards,
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Amy Wang
TechNet Community Support

Similar Messages

How many DNS record need to create in Internal & external DNS server for exchange?

Hi friends,
I recently installed Exchange Server 2010 in my organization for testing purpose and I've register a pubic ip too for exchange server on godaddy.com. How many
internal & External DNS records reqired to configure on external & Internal dns server so my all feature like Auto-discover, Activ -sync,& webmail start working perfectly.
It's my first time configuring exchange for a organization.
Thanks & Regards,
Pradeep Chaugule

Hi,
Just as what ManU Philip said, you need to create
Autodiscovery.domaincom and mail.domain.com for external dns server.
Generally, you configure your Exchange Servers as DNS clients of your internal DNS server.
Refer from:
http://technet.microsoft.com/en-us/library/aa996996(v=exchg.65).aspx
Best Regards.

Move Mailboxes from Exchange 2007 to Exchange 2013 (Could not find a valid mailbox migration for esta organization)

Hi all, I am in full migration from Exchange 2007 to Exchange 2013 and everything went correctly.
I have migrated several mailboxes and are working well. But a few days ago, when I try to migrate a mailbox I get the following error and can not migrate:
"Could not find a valid mailbox migration for this organization"
Do you know that you can be?
regards
Microsoft Certified IT Professional Server Administrator

Hi,
From your description, the issue should be related to the migration mailbox. I recommend you check if the following account is existed in ADUC.
Migration.8f3e7716-2011-43e4-96b1-aba62d229136
If this account does not exist, you need to run setup /prepareAD and then enable this migration mailbox to check the result.
Hope this can be helpful to you.
Best regards,
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Amy Wang
TechNet Community Support

Are there any out the box tools for detailing Exchange organization ?

Are there any tools which we go out an audit an exchange enviornment showing the servers, roles and configuration ? it needs to be able to get this information ideally for all versions of Exchange 2003, 2007, 2010 and 2013.
Thanks in advance.

You can collect the Organizational Health in Exchange 2010 console for Exchange 2003/2007/2010 and that will list very useful information about statistics in your organization like servers, databases, CALs, recipient, feature used etc...
Collect Organizational Health Data -
http://technet.microsoft.com/en-us/library/dd351156%28v=exchg.141%29.aspx
However it doesn't contain any configuration information and that you need to collect it manually because that depends on needs of each organization and how they want to setup their infrastructure...

Exchange 2003 SMTP resolves to incorrect MX record for Outbound emails

Starting October 2007, we have encountered numerous incidents where users complaint that they can not send emails to randomly with Relayed Denied error.
First we thought the problem is with the receipient servers, but after reviewing the SMTP log intensively, I have noticed that the SMTP service on Exchange Server 2003 SP2 tries to send out emails to wrong IP Addresses (instead of sending out to listed IP of MX record, it tries to send to primary domain IP address).
To test further, we have changed the DNS server of the Exchange Server to public DNS service provided by the ISPs and still received same result.
If the user tries to send the email again (from the bounced back message), it some times goes through.
Has anyone know what the problem is?
Have checked the server configuration, DNS configuration, ran all updates, and yet still same result. Is one of the Microsoft Updates causing this issue?

Here is the official explanation i got from MS, sounds like it is doing what they expect it to do.
Problem Description
When Exchange 2003 sends e-mail to the Internet using DNS to resolve external domain names a DNS query is done for the remote domain's MX records. In the event that the initial MX query returns a "server failure", Exchange 2003 will fall back to a DNS A record query. If this query is, in turn, successful and there is an A record for the domain in question that happens to be listening on port 25, Exchange will make a connection to that server. However, if this server does not relay, or accept e-mail for the intended domain a NDR will be generated with a 5.7.1, or
5.5.0 error message.
There are several domains that have A records that point to IP addresses that accept connections on port 25, but do not relay for the same name space:
Eg: Mindspring.com; Earthlink.net
Resolution
Resolve the DNS resolution problems that are causing occasional MX record failures.
Examples:
1. The Exchange server has multiple default gateways set on a multi-homed server.
This is not a recommended configuration and can cause a number of unexpected network problems. If the internal DNS server the internal NIC points to cannot resolve external DNS queries, this problem can occur.
Action: remove the default gateway from one of the NICs.
This doesn’t applies to us, as we don’t use Internal DNS
2. If the Exchange server points to multiple DNS servers on TCP/IP properties, or on the SMTP Virtual Server properties, verify that each of these DNS servers will return MX records properly. If one of the DNS servers does not return DNS records consistently, rectify this problem.
Action: remove this DNS server from the external DNS tab.
Workaround:
Bypass DNS by creating a SMTP connector with address space of <domain.com> and forward to smart host as the IP address the MX/A points to.
Exchange Query Explained
1. If Exchange finds the MX record(s) for a remote domain (through DNS query) it will not fall back to an A record query in the event the MX record (more precisely, the A record the MX record points to) is temporarily not responding on port 25. Instead, Exchange will try another MX record if one exists. If no other MX records exist and none are responding on port 25, the queue will go into a retry state for this remote domain. When that retry state has expired, Exchange will again attempt to resolve MX records for this domain, and so on.
2. Exchange will fall back to an A record query for the remote domain in the event that no MX record can be found. This is not to say that the MX record does not exist - only that when Exchange issued a DNS query for the remote domain the DNS response was "server failure", which basically means no MX was found. So, the MX record may indeed exist, but Exchange simply could not find it through DNS resolution.
3. Exchange then queries the A record and this happens to return a result. If the A record is listening on port 25, but does not accept mail for <domain.com> then we will get the NDR with 550 5.7.1 unable to relay (or some variation of this NDR error code) when Exchange connects and attempts to send the e-mail.
So, the intermittent nature of the problem is caused by a failure to find the MX record and a success in finding A record. This can happen for a variety of reasons, but it boils down to flakey DNS resolution.
For example:
a. A bad DNS server listed as a forwader on the DNS server.
b. A bad DNS server on the TCP/IP properties.
c. A bad DNS server on the SMTP VS (external DNS servers)
d. Multiple default gateways on Exchange (ie. multiple NICs on different networks, each NIC having a default GW)
A netmon on Exchange will show the failed MX lookup and successful A record lookup; however, it may not be conclusive unless the "bad" DNS server is listed in the netmon trace. For example, if Exchange points to internal DNS server(s) for name resolution and these DNS servers service these DNS queries by Exchange, you may need a netmon on the DNS server(s) as well to determine which DNS server/Forwarder/etc is at fault.
Regards,
Shahul Hameed Dasthagir
Support Engineer | Enterprise Communications Support

Preparing Domain for Exchange 2013 in an Exchange 2010 Organization

When preparing the domain for Exchange 2013, can we use the same Organizational Name as was used for Exchange 2010 or should we select a new variation?

When preparing the domain for Exchange 2013, can we use the same Organizational Name as was used for Exchange 2010 or should we select a new variation?
You dont have define the org name since it already exists.
Twitter!: Please Note: My Posts are provided “AS IS” without warranty of any kind, either expressed or implied.

Troubleshooting and Introduction for Exchange 2007/2010 AutoDiscover - Details about "Test E-mail AutoConfiguration"

AutoDiscover is a new feature in Exchange 2007, to provide access to Microsoft Exchange features (OAB, Availability service, UM) for Outlook 2007
clients or later.
We can determine whether problems related to AutoDiscover via OWA.
For example:
OOF is not working in Outlook Client but it is working in OWA.
When we realized this issue is not related to Outlook Client side and network side after performing some troubleshooting steps, it should be something
abnormal on AutoDiscover.
There is a common tool to check AutoDiscover in Outlook, Test E-mail AutoConfiguration.
Today, we will introduce AutoDisocver and “Test E-mail AutoConfiguration” in details. Hope it is helpful for AutoDiscover troubleshooting and self-learning.
1. Differences between “Test E-mail AutoConfiguration” and other tools
The “Test-OutlookWebServices” cmdlet allows us to test the functionality of the following services:
Autodisocver
Exchange Web Services
Availability Service
Offline Address Book
When we run “Test-OutlookWebServices”, it returns all the web services’ states.
However, some information are useless for some scenarios.
For example:
We just want our Exchange 2010 Server working internally. So it is unnecessary to enable Outlook Anywhere.
However, when we run “Test-OutlookWebServices”, it returns Outlook Anywhere errors because the Outlook Anywhere does not need to been enabled.
In contrast, using “Test E-mail Autodiscover” is more intuitive.
If there is any problems, it will return error code from the test result, like 0x8004010F etc. We can do some research from TechNet articles or MS
KBs.
Although it is difficult to say where the specific problem is just via the error codes, we can combine with IIS logs to perform troubleshooting and
find the root of problem.
2. How to use “Test E-mail AutoConfiguration” Tool
a. Open Outlook, we can find there is an Outlook Icon at the right bottom of System tray. Holding down “Ctrl” button and right click the Outlook Icon, we will see “Test E-mail
AutoConfiguration” option. Please see Figure 01.
Figure 01
b. Click “Test E-mail AutoCofiguration” and input user name, uncheck the “Use Guessmart” and “Secure Guessmart Authentication” checkboxes, then click “Test”. Please see
Figure 02.
Figure 02
c. “Test E-mail AutoConfiguration” result panel and log panel. Please see Figure 03 and Figure 04.
Figure 03
Figure 04
3. How to understand “Test E-mail AutoConfiguration” result
According to the Figure 03, we found there are many URLs in the “Test E-mail AutoConfiguration” result panel. Let us understand the details of these
URLs.
If we these URLs are not the correct ones, we can re-setting or re-creating them via commands.
- Internal OWA URL:
https://vamwan310.vamwan.com/owa/
OWA internal access.
- External OWA URL:
https://mail.vamwan.com/owa/
OWA external access.
- Availability service URL:
https://vamwan310.vamwan.com/EWS/Exchange.asmx
Free/Busy, OOF and meeting suggestions.
- OOF URL:
https://vamwan310.vamwan.com/EWS/Exchange.asmx
Out of Office access.
- OAB URL:
https://vamwan310.vamwan.com/OAB/023ef307-b18a-4911-a52c-de26700f6173/
OAB access.
- Exchange Control Panel URL:
https://vamwan310.vamwan.com/ecp/
ECP access.
4. AutoDiscover Tips
- AutoDiscover Service itself is a web application running on the AutoDiscover virtual directory (not a server service) designed to provide connection information to various
clients.
- The AutoDiscover service is automatically installed and configured when CAS role is added to any Exchange Server.
- AutoDisocver virtual directory is created in IIS within the Default Web Site.
- A Sercive-Connection-Point (SCP) object is created in AD.
- The SCP contains a URL to the AutoDiscover service. This is for intranet clients so they do not have to use DNS to locate the AutoDiscover service.
- In AD this object is located at the following location:
DC=<domain>, CN=Configuration, CN=Services, CN=Microsoft Exchange, CN=First Organization, CN=Administrative Groups, CN=Exchange Administrative
Group, CN=Servers, CN=<CAS Name>, CN=Protocols, CN=AutoDiscover, CN=<CAS Name>
- Setup creates the AutoDiscover URL based on the following structure:
<CASNetbiosName>.domain.com/AutoDiscover/AutoDiscover.xml
If a PKI certificate is not already present, a self-signed certificate is installed on the Default Web Site.
To help allow this certificate pass the Issues to test it is set up with a Subject Alternative Name containing urls.
If a PKI certificate is present, that certificate is utilized and configured for use in IIS.
The Outlook Provider is used to configure separate settings for the Exchange PRC protocol (internal to network), Outlook Anywhere (Exchange HTTP protocol), and WEB:
EXCH, EXPR, WEB
The
EXCH and EXPR setting are vital for the proper configuration of Outlook.
5. AutoDiscover Workflow
General Process flow:
There are various components surrounding the AutoDiscover Service and all are necessary to complete a request. Including IIS, AutoDiscover service
itself, the provider, and AD.
a.
Client constructs service URL and submits Autodiscover Request. First attempt to locate the SCP object in AD. So, DNS is not needed.
b.
IIS Authenticates User.
c.
Is the Autodiscover service in the appropriate forest?
+ If YES.
    1)
Parse/Validate Request
    2)
Is there a provider that can service the Request?
++ If YES
      a)
Config provider processes request and returns config settings.
      b)
Return config setting to client
++ If NO
Inform client we cannot process request
+ If NO.
Redirect client to Autodiscover service in the appropriate forest.
Methods to find Autodiscover services: SCP and DNS
Domain-joined
a. Find SCP first.
The SCP contains the URL to the AutoDiscover service.
URL: https://CAS01.contoso.com(CAS’ FQDN)/AutoDiscover/AutoDiscover.xml
If more than one SCP object is found in AD (it means there are multiple CAS servers in the Exchange organization), Outlook client will choose one of the SCP entries that
are in the same site to obtain the AutoDisocover URL.
b. If we cannot find SCP object, then Outlook client will use DNS to locate AutoDiscover.
Outlook parses out the domain (SMTP suffix) via your EmaiAddress, then attempts to connect to the predetermined order of URLs via the suffix.
For example: If my email address is
[email protected]
Outlook tries POST commands to the following order of URLs:
https://contoso.com/autodiscover/autodiscover.xml
https://autodiscover.contoso.com/autodiscover/autodiscover.xml
NOTE: The URLs above is by design, hardcode
and cannot be changed.
c.
If those fail, Outlook tries a simple redirect to another URLs in IIS:
http://contoso.com/autodiscover/autodiscover.xml
http://autodiscover.contoso.com/autodiscover/autodiscover.xml
If none of these URLs work then DNS is most likely not set up correctly.
We can test that by pinging one of the above URLs.
If that is successful, we must ensure the URLs contoso.com or autodiscover.contoso.com are actually pointing to the CAS server.
If the ping fails then there is a chance that DNS is not set up correctly so be sure to check that the URLs are even registered.
NOTE: If contoso.com is a non-CAS server,
we should add a Host record with just AutoDiscover. And point that entry to your CAS server that is running AutoDiscover.
d.
If still failed, we can use DNS SRV lookup for _autodiscover._tcp.contoso.com, then “CAS01.contoso.com” returned. Outlook will ask permission from the user to continue
with AutoDiscover to post to https://CAS01.contoso.com/autodiscover/autodiscover.xml
Non-Domain-joined
It first tries to locate the Autodiscover service by looking up the SCP object in AD. However the client is unable to contact AD, it tries to locate
the Autodiscover service by using DNS.
Then, same as step b, c, d in
Domain-joined scenario.
6. How to change the AutoDiscover
service location order forcibly?
By default, Outlook client locates AutoDiscover service in that order above.
We can also change the order forcibly.
a.
If we want to locate AutoDiscover service via one of the autodiscover URLs, please running following command in EMS:
Set-ClientAccessServer -identity <servername> -AutodiscoverServiceInternalUri https://autodiscover.contoso.com/autodiscover/autodiscover.xml(URL
that you want)
b. If we want to locate AutoDiscover service via
SRV record, please follows this KB to set up SRV:
http://support.microsoft.com/kb/940881
7. How to check AutoDiscover Healthy
a. We should make sure the AutoDiscover
is healthy before using AutoDiscover to perform troubleshooting.
b.
We can browse following URL in IE explorer:
https://autodiscover.vamwan.com/autodiscover/autodiscover.xml
If it returns “code 600”, that means AutoDiscover is healthy.
Screenshot as below:
c. AutoDiscover itself returns errors to the requesting client if the incoming request does not contain the appropriate information to complete a
request.
The following table explains the possible errors that could be returned.
Error Value
Description
600
Mailbox not found and a referral could not be generated.
601
Address supplied is not a mailbox. The provided email address is not something a client can connect to. It could
be a group or public folder.
602
Active Directory error.
603
Others.
The 600 “Invalid Request” error is returned because a user name was not passed to the service. That is OK for this test because this does confirm
the service is running and accepting requests.
d.
If AutoDiscover service is not working well, I suggest re-building the AutoDiscover Virtual Directory for testing.
Steps as below:
1) Running following command in EMS to remove the AutoDiscover VD (we cannot delete it via EMC):
Remove-AutodiscoverVirtualDirectory -Identity "CAS01\autodiscover(autodiscover.contoso.com)"
Please refer:
http://technet.microsoft.com/en-us/library/bb124113(v=exchg.141).aspx
2)
Running following command in EMS to verify whether we have removed the AutoDisocver VD successfully:
Get-AutodiscoverVirtualDirectory | FL
Please refer:
http://technet.microsoft.com/en-us/library/aa996819(v=exchg.141).aspx
3)
Running following command in EMS to re-creating a new AutoDiscover VD:
New-AutodiscoverVirtualDirectory -Websitename <websitename> -BasicAuthentication:$true -WindowsAuthentication:$true
Please refer:
http://technet.microsoft.com/en-us/library/aa996418(v=exchg.141).aspx
8. Common issues
a. Outlook Disconnection
Issue and Troubleshooting
Issue:
Sometimes the Outlook clients cannot connect to the Exchange server after migrating to a new Exchange server or changing to new CAS. The Outlook clients
always connect to the old CAS server.
Troubleshooting:
To solve this issue, we should change the SCP via following command:
Set-ClientAccessServer -Identity
<var>CAS_Server_Name</var> -AutodiscoverServiceInternalUri
https://mail.contoso.com(newCAS’FQDN)/autodiscover/autodiscover.xml
b. Autodiscover
Certificate issue
Tips on Certificate:
Exchange requires a certificate to run an SSL protocol such as HTTPS. We can use the certificate that supports subject alternate names (SAN) in Exchange.
This is to allow the certificate to support resources that have different names, such as Outlook Anywhere and the Autodisocver Web application.
Issue and Troubleshooting
Issue:
We receiver the Certificate Principal Mismatch error when we use a SAN certificate.
Troubleshooting:
1) Please determine the FQDN that the client
uses to access the resource. Steps as below:
OutlookàToolsàAccount
SettingsàE-mailàclick
the Exchange accountàChangeàMore
SettingsàConnectionàExchange
Proxy Settingsànote the FQND that list in the
Only connect to proxy servers that have this principal name in their certificate box.
2)
Please using EMS to determine the value for the CerPrincipalName attribute: Get-OutlookProvider
This command returns the result for the EXPR name.
3)
Please re-setting the CertPrincipalName attribute to match the FQDN via following command:
Set-OutlookProvider EXPR –CertPrincipalName: “msstd:<FQDN the certificate is issued to>”
9. Resource for reference:
Autodiscover and Exchange 2007
http://technet.microsoft.com/en-us/library/bb232838(v=exchg.80).aspx
White Paper: Understanding the Exchange 2010 Autodiscover Service
http://technet.microsoft.com/en-us/library/jj591328(v=exchg.141).aspx
Certificate Principal Mismatch
http://technet.microsoft.com/en-us/library/aa998424(v=exchg.80).aspx
Please click to vote if the post helps you. This can be beneficial to other community members reading the thread.

HI,
I get following? when run the test? user is login to Domain A but accessing exchange in Domain B?

Discontinuing Forefront Protection 2010 for Exchange

Hi
Microsoft is discontinuing any further releases of Forefont Protection 2010 for Exchange Server:
http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx
We have a lot of customers with on-premises Exchange Servers, to which we sold Forefont Protection 2010 for Exchange Server.
What is the alternative for that product, Forefront Online Protection?
What is the Scenario, if a customer don't want his mx record to point to Microsoft?
Regards
Peter

Hi,
I'm sorry but yesterday I was working with a customer.
This is going to be a long post :-)
Exchange 2010 has no native antivirus/malware protection. This kind of protection is provided by Forefront Protection 2010 for Exchange.
Those filters provide antispam protection therefore from this point of view I wouldn't consider them a replacement for Groupshield AV protection on Exchange 2010.
This is the fast answer :-)
Let's move to the longer one.
There are going to be a lot of assumptions because I don't know your environment at all and this is something which should be carefully planned and tailored based on your business needs.
Assumptions:
You have an Exchange 2010 Organization
There are no Edge servers
You are following the common scenario with an AV for Exchange (Groupshield) running on Hub and Mailbox servers, Postini for Inbound/Outbound traffic protection from AV and SPAM (MX record pointing to Postini) and an AV for Filesystem running on the Exchange
servers
You are planning to move to Exchange 2013 in the future (let's say 6 months/1 year from now)
You are open to discuss a Microsoft-oriented solution without 3rd party software
We are not going to discuss licensing (we are lucky and someone else will decide for us :-))
We are not going to discuss the differences between Postini/Groupshield/Forefront/Exchange agents because I don't know them well enough to tell you something which would make sense and I'm still discussing if it was better the Commodore 64 or the Amiga
(obviously Commodore 64)
We are looking for a solution which should cover as many scenarios as possible
Short-term objective: Achieve antivirus/antispam protection on Exchange 2010 and get rid of Groupshield (and may be of Postini with it)
Long-term objective: Migrate to 2013 and leverage the antimalware and antispam agents included in the product
Act 1 - Short-term objective:
Inbound/outbound traffic:
The antispam agents can be installed on an Exchange 2010 Hub server but the place where they should be used is the Edge server.
Solution 1: Replace Postini with 2 Exchange 2010 Edge servers (MX record pointing to the Edge servers). Antivirus protection will be provided by Forefront Protection 2010 for Exchange (FPE) . Antispam protection by Exchange 2010 and FPE (which expands the antispam
capabilities of Exchange 2010)
Solution 2: Replace Postini with Forefront Online Protection for Exchange (FOPE)
Internal traffic:
Solution: FPE will replace Groupshield on the Hub servers. No antispam agents installed. FPE will be installed as a Transport Agent
Database Content (aka all that stuff that doesn't pass through transport):
Not all Exchange data are passing through the Hub transport (i.e. Drafts, Calendar, Contacts, Public Folders, etc...)
Solution 1: FPE will replace Groupshield on the Mailbox servers. FPE will leverage the Virus API (VSAPI) to access the content of the Store
Solution 2: The AV installed on your clients has an Outlook plug-in which scans the content of the store client-side
This should provide enough AV/antispam protection and you will have an homogeneous solution where all components are able to interact smoothly (Outlook Junk Mail, Antispam agents, safe senders, safe recipients, etc...) without much effort in terms of 3rd
party plug-ins, different administration consoles, different places where you have to check if the message has been blocked.
I know what is going to be the fate of Forefront but this is to meet our short-term/immediate objectives. From now on we will have until December 2015 to plan our migration to Exchange 2013.
The screen fades to black. Voice-over announces that you migrated to Exchange 2013 :-)
Act 2 - Long-term objective:
Inbound/Outbound traffic:
Solution 1: Leverage the AV and antispam agents on your published MBX/CAS servers
Solution 2: Use FOPE
Internal Traffic:
Solution: Leverage the AV agent on your MBX/CAS servers
Database content:
In Exchange 2013 the VSAPI is dead. Any AV for Exchange will have to use transport agents on Exchange 2013. The only possible exceptions is using Web Services for the On-demand scan of a limited number of mailboxes.
Solution: The AV installed on your clients has an Outlook plug-in which scans the content of the store client-side
The screen fades to black. Credits.
There are a few considerations related to these design changes which demonstrates that IMHO they are a good choice but they would be too long to discuss in this post and they would probably be OT. I'm thinking to write a blog when I'll have some time.
IMPORTANT: These are just my 2 pence. You should discuss this with someone which knows your infrastructure. The above solutions are at best incomplete because there a lot more factors which come into play when choosing a design like this.
My personal advice is to involve your TAM (if you have one) and work with my colleagues to find the solution best suited for your company.
Bye
Gabriele
P.S. Pure self-advertising: If you are in Switzerland you are not far from me :-D
-- Gabriele Tansini [MSFT] This posting is provided "AS IS" with no warranties, and confers no rights"

#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##

Hi,
This is my first post here.
My exchange server of late is facing a peculiar problem. I get the error message that I have posted below when sending mails to any outside domain. However when I restart the server the mails can be resend to the address without any issue. After a certain
time again the issue pops up upon which I am forced to restart the server again. I am running 2007 Exchange on Windows 2003.
Generating server: name.mydomain.com
[email protected]
#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##
[email protected]
#554 5.4.4 SMTPSEND.DNS.MxLoopback; DNS records for this domain are configured in a loop ##
Original message headers:
Received: from name.mydomain.com ([1xx.xxx.xxx.xx5]) by MHDMAILS.mouwasat.com
([1xx.xxx.xxx.xx5]) with mapi; Wed, 19 Oct 2011 08:56:29 +0300
From: <[email protected]>
To: <[email protected]>
CC: "Al Alami,Tareq" <[email protected]>
Date: Wed, 19 Oct 2011 08:56:27 +0300
Subject: RE:
Thread-Topic:
Thread-Index: AcyAQ5tu8z9CvBfdT5+1pcGQkk6x0AIuwczAAAGZjeABQyW5sAADeeJQAAETNDA=
Message-ID: <[email protected]>
References: <[email protected]com>
<[email protected]com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related;
            boundary="_004_EEC8FA6B3B286A4E90D709FECDF51AA06C0588CA11namedomain_";
            type="multipart/alternative"
MIME-Version: 1.0

On Sun, 23 Oct 2011 15:05:15 +0000, Jobin Jacob wrote:
>
>
>Even af
>
>ter removing my domain from the send connector I continue to receive the error. I would like to say I do have a firewall, Cyberoam. However, it was the same configuration till now in the firewall. I did try Mx lookup and found the following.
>
>Could there be any other solution to this issue ?
Sure, but it's necessary to ask a lot of questions since none of us
know how your organization is set up.
I see you also have "Use the External DNS Lookup settings on the
transport server" box checked. How have you configured the "External
DNS Lookups" on the HT server's property page? Is there any good
reason why you aren't just using your internal DNS servers? If the
internal DNS servers are configured to resolve (or forward) queries
for "external" domains then there's no reason to use that checkbox. In
most cases checking that box is a mistake.
http://technet.microsoft.com/en-us/library/aa997166(EXCHG.80).aspx
The behavior you describe (it works for a while and then fails;
restarting the server returns it to a working state) sure sounds like
some sort of DNS problem.
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

After adding SPF records for Hybrid Development some external mails bounced back with error SPF Unauthorized mail is prohibited.

Added v=spf1 include:spf.protection.outlook.com -all and the txt token for the Exchange 2013 hybrid configuration, now some mails bounced back with the error "SPF Unauthorized mail is prohibited". What could be the cause? Should I customized
the SPF record but it is not mentioned in the procedures for Hybrid configuration to do that.

Hi,
Would you like to mark Ed's reply as an answer so that others can find the solution easily.
Have a nice day : )
Thanks
Mavis
Mavis Huang
TechNet Community Support

Legacy Namespace for Exchange 2007 to 2013 co-existence

We are migrating from Exchange 2007 to 2013, during the co-existence phase, where is the legacy.{domain.com} namespace used? We are at the point now that we want to move all services over to the Exchange 2013 CAS servers, however... GPO settings
are used to point outlook clients to mail.{domain.com} for Outlook Anywhere. If DNS is updated to point mail.{domain.com} to the Exchange 2013 servers, will there be an issue with connectivity for people still on the Exchange 2007 servers? Do these people
need to point to legacy.{Domain.com} or will mail.{domain.com} proxy the connection to the legacy namespace? I would like to know if the GPO settings will interfer with the settings that Autodiscovery provide back.
I have read a bunch or articles on the approach, but I am still fuzzy on where legacy.{domain.com} comes into play.
Thanks in advance for your help.

In coexistence with exchange 2013 and legacy version the request happens in 2 types.
For Exchange 2010 –
Exchange 2013 does a Proxy for owa and ews requests for users in exchange 2010.
For Exchange 2007 –
Exchange 2013 does redirection for owa and ews requests for users in Exchange 2007.
Certificates:
All the required SAN entries for UM,webservices and activesync should be created.
Add external owa legacy URL to the public certificate and install it on both Exchange 2007 and
Exchange 2013 only then owa redirection will work.
You need to Include internal Legacy. Domain.com on Exchange 2007 Certificate for OWA co-
Existence.
Following change needs to be done in Firewall
External OWA URL should be directed to exchange 2013 Internet Facing CAS.
External EWS URL should be directed to exchange 2013 Internet Facing CAS.
External Autodiscover URL should should be directed to Exchange 2013 CAS.
External ActivesyncVirtualDirectory should be directed to Exchange 2013 CAS.
External UMvirtualDirectory should be directed to Exchange 2013 CAS.
Create new NAT rule on firewall for Legacy.domain.com to Exchange 2007 CAS. You can do this as well.By doing this users will be able to log on directly using the URL https://legacy.domain.com/owa with
a mailbox on Exchange 2007.
External and Internal DNS settings
Public DNS - Map all of your external public DNS records (ews,owa,activesync etc.,) to your
exchange 2013 public IP if you have dedicated one for 2013 or FQDN of your internet facing CAS server.
Example:
Current external owa URL (contoso.domain.com) – point it to dedicated exchange 2013 public ip or internet facing exchange 2013 CAS FQDN.
Current External Autodiscover – point it to dedicated exchange 2013 public ip or internet
facing exchange 2013 CAS FQDN
Internal DNS – Configure the Exchange 2007 to point SCP AutoDiscoverURI to Exchange 2013 Client
Access FQDN by changing DNS entry for Autodiscover.domain.com to exchange 2013 CAS sever Ip
address
The internal DNS records should point to the internal host name and IP address of your Exchange
2013 Client Access server
Make sure that legacy.contoso.com resolves to CAS2007 in internal and external DNS.
Authentication Settings:
This part is little bit tricky. You need to plan according to your organization. If you have FBA configured in TMG or ISA server then you need to configure accordingly.
Set the owa virtual directory authentication only to Basic in exchange 2007.
In exchange 2013 set owa virtual directory to only (Windows Authentication) or only (form-based authentication) or only (Basic, No redirection, SSL Enabled) depends according to your setup.
Things to check:
If you have redirection configured in IIS on the Exchange 2007 Server Make sure that the above
Virtual Directories doesn’t have it configured.
If you have FBA enabled on ISA or TMG then disable FBA on Exchange 2013 CAS else users will be prompted twice for authentication
For further references you can refer my article below
http://exchangequery.com/2014/09/24/owaews-configuration-in-exchange-20132007-coexistence/
Remember to mark as helpful if you find my contribution useful or as an answer if it does answer your question.That will encourage me - and others - to take time out to help you Check out my latest blog posts on http://exchangequery.com Thanks Sathish (MVP)

How to use Purch. Info Record, for different Valuation Types ?

Hi All,
While doing Split Valuation,
I have created three valuation types - say, M1,M2,M3. for material M.
Now, I want to create Info record for material M and Vendor V1.
when i go to me11, system is allowing me to create info record for M and V1 once only,
in Purchasing Organization View, I'm getting the Valuation type field,
but can't entering 3 prices for 3 valuation types,
such as in Material Master.
Can any one help me regarding this....
Thanks,
Anand.

if u create po with info update indicator then u can use your valuatiion type in po for whihc there is no ifo recrod existing then system willl createt one
but actually the price will get stored in the price oder history not exactly in the pir

"Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run se

Team,
I am trying to Install Exchange on my Lab, getting below error
message.
The Schema Role is installed on Root Domain and trying to install
exchange on Child domain.
1 Root Domain - 1 Child domain. both are located on single site.
“Setup encountered a problem while validating
the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run setup with the /prepareAD parameter and wait for
replication to complete.”
Followed below articles:
http://support.risualblogs.com/blog/2012/02/21/exchange-2010-sp2-upgrade-issue-exchange-organization-level-objects-have-not-been-created-and-setup-cannot-create-them-because-the-local-computer-is-not-in-the-same-domain-and-site-as-the-sche/
http://www.petenetlive.com/KB/Article/0000793.htm
transferred the schema roles to different server on root domain, still no luck.
can someone please help me.
regards
Srinivasa k
Srinivasa K

Hi Srinivasa,
I guess, you didn't completed the initial setup schemaprep and adprep before starting the installation. You can do it as follows:
1. Open command Prompt as administrator and browse to the root of installation cd and run Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
After finishing this,
2. Setup.exe /PrepareAD /OrganizationName:"<organization name>" /IAcceptExchangeServerLicenseTerms
3. To prepare all domains within the forest run Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms. If you want to prepare a specific domain run Setup.exe /PrepareDomain:<FQDN of the domain you want to prepare> /IAcceptExchangeServerLicenseTerms
4. Once you complete all of the 3 steps, install the pre-requisities for Exchange 2013
5. Finally, run the setup program
Hope this will help you
Regards from Visit ExchangeOnline |
Visit WindowsAdmin

Namespace for Exchange 2003 == 2010 == 2013 Migration

Hi
Hope someone can help. I am working on an Exchange 2003 to 2010 migration, which will then quickly move onto a 2010 to 2013 migration and need some clarification on the namespaces to use. I am aware that if I do not do this right at the 2003
to 2010 migration, this will cause a headache at the 2010 to 2013 migration.
Some background:
2003 Functional Level Domain - 2 x 2008 DC's
Currently users are on a 2003 exchange cluster with a mix of RPC (internal users) and RPC over HTTP connections (roaming users)
We will be installing Exchange 2010 on a single server, with CAS, HUB and Mailbox roles and no load balancer, as we will be moving quickly to 2013.
We have two Kemp load balancers ready for Exchange 2013.
Exchange 2010 is installed on a single server (exh2010.domain.local) and configured with an CAS array name (exh-cas.domain.local) which is resolvable internally only.
Currently we have multiple smtp namespaces e.g. @company.com, @company2.com.
Our main website etc is www.company.com
Our public facing services are at https://service.mycompany.com
Our 2003 RPC address is https://webmail.mycompany.com
I understand that the 2010 RPC CAS array name should be separated from the Outlook Anywhere (RPC over HTTPS) address so that when 2013 takes over the HTTPS address, the RPC connections are not broken.
Two Questions:
Do we have to use the HTTPS same namespace for 2013 as we do in 2010? Its just I would want to test the Kemp load balancers before making them live (slow careful transition), and giving them a different namespace, e.g.
https://mail.mycompany.com would allow a migration, rather then a cutover.
Can we use the *.mycompany.com address rather then the company.com address, even though we have no SMTP addresses at mycompany.com? Can autodiscover still work?
Thanks in advance for any guidance
Cheers
Steve

1. No, but you can. Exchange 2013 will proxy all services for Exchange 2010, so if you set up everything right, you should be able to simply swing the name from Exchange 2010 to 2013.
2. Your web services can be published with any domain as long as the hostname is in the certificate. Only Autodiscover needs to match the e-mail domain(s). So in your example, you could publish OWA, ECP, ActiveSync, Web Services and OAB
at owa.mycompany.com. You would need autodiscover.company.com, autodiscover.company2.com, etc., but if you don't have e-mail addresses with mycompany.com, you don't need autodiscover.mycompany.com. If all users have a company.com e-mail address,
the you only need autodiscover.company.com as long as users know to enter that e-mail address when configuring profiles on PCs or devices. If you're going to have to have Autodiscover for multiple domains, then you might consider using an SRV record
instead because it can greatly simplify your certificate requirements.
Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

BPA shows domain prepped for Exchange 2007 SP1 after SP3 install

Hello,
I have a Client with a domain that is at 2003 domain functional level and 2000 forest level.
The client had Exchange 2007 SP1 and I have just upgraded it to SP3. There is one CAS, one Hub Transport, and one Mailbox Server (All three had Exchange 2007 SP1).
The domain and forest were prepped earlier by someone else and when I ran the installation program, it didn't pop up any errors on any of the servers.
The upgrade to SP3 is in preperation to Exchange 2010. Everything is working ok. I have checked:
1) In ADSIEdit, Exchange System Objects properties: Object Version =11221.
2) In ADSIEdit, Services>Microsoft Exchange>Organization: Object Version =11222
3) In ADSIEdit, RangeUpper value of ms-Exch-Schema-Version-Pt object = 14625
However, When I run the Exchange BPA, it reports that the domain is prepped for Exchange Server 2007 Service Pack 1 (In informational items). This is an informational item and not a warning or alert. However, I am concerned. Is this normal, and will it affect
the migration to Exchange 2010?
Thanks,
HA

Hello Ha20,
Based on my experience, it will not affect the migration. However, it’s recommended to prepare the schema again to avoid any potential issues.
Thanks,
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact
[email protected]
Simon Wu
TechNet Community Support

Txt record for exchange organization

Similar Messages

Maybe you are looking for