http://support.microsoft.com/kb/q152959/
Pour éviter tout problème, effectuez les procédures suivantes avant de supprimer le premier ordinateur Exchange Server sur le site :
IMPORTANT : Si cet ordinateur Exchange Server contient des dossiers publics ou utilisateurs (extérieurs au site), vous devrez déplacer les boîtes à lettres correspondantes vers un autre serveur du site et répliquer tout dossier public sur les autres serveurs du site afin d'éviter toute perte de données. Pour plus d'informations, reportez-vous au Guide de l'administrateur Microsoft Exchange Server, chapitres 12 et 15.
Carnet d'adresses hors connexion :
Choisissez un serveur du site pour contenir le Carnet d'adresses hors connexion.
Cliquez sur l'objet Banque d'informations publique, puis cliquez sur Propriétés.
Cliquez sur l'onglet Instances.
Dans la liste Dossiers publics, sélectionnez Carnet d'adresses hors connexion et Carnet d'adresses hors connexion version 2 (le cas échéant), puis cliquez sur Ajouter. Un réplica de ces dossiers est ainsi créé sur le serveur que vous avez choisi à étape 1.
Cliquez sur OK.
À l'aide du programme Administrateur Exchange Server, cliquez sur le conteneur Configuration et ouvrez les propriétés de l'objet Configuration du service annuaire du site.
Dans la liste Serveur du carnet d'adresses hors connexion, cliquez sur le serveur que vous avez choisi à l'étape 1.
Informations de disponibilité Schedule+ et Formulaires de l'organisation :
Choisissez un serveur dans le site pour contenir les informations Schedule+ et les formulaires de l'organisation.
À l'aide du programme Administrateur Exchange Server, cliquez sur le conteneur Configuration, sur le conteneur Serveurs, puis sur le serveur que vous avez choisi à l'étape 1.
Cliquez sur l'objet Banque d'informations publique, puis cliquez sur Propriétés.
Cliquez sur l'onglet Instances.
Dans la liste Dossiers publics, sélectionnez Informations de disponibilité Schedule+ et Formulaires de l'organisation, puis cliquez sur Ajouter. Un réplica de ces dossiers est ainsi créé sur le serveur que vous avez choisi à étape 1.
Cliquez sur OK.
Une instance du dossier Informations de disponibilité de Schedule+ est ainsi créée. Le dossier public Informations de disponibilité Schedule+ d'origine est supprimé lors de la suppression du premier site, et la nouvelle instance devient alors active.
Serveur de calcul du routage :
Choisissez un serveur du site comme nouveau serveur de calcul du routage.
À l'aide du programme Administrateur Exchange Server, cliquez sur le conteneur Configuration, puis double-cliquez sur l'objet Adressage du site.
Cliquez sur l'onglet Général.
Dans la liste Serveur de calcul du routage, cliquez sur le serveur que vous avez choisi à l'étape 1. Vous devez effectuer certains autres changements dans les pages de propriétés pour activer le bouton Appliquer, de façon à ce que les modifications soient conservées.
Cliquez sur l'onglet Routage, puis sur Recalculer le routage.
Cliquez sur OK.
Pour finir, effectuez la procédure décrite dans l'article suivant :
189286 (http://support.microsoft.com/kb/189286/[FR]/ ) XADM : Comment faire pour supprimer un serveur d'un site
REMARQUE : Microsoft recommande d'éteindre le premier serveur du site ou de le déconnecter du réseau temporairement après l'exécution des procédures ci-dessus pour vérifier si l'opération a réussi. Après avoir vérifié que les modifications apportées fonctionnent correctement (en démarrant un client Microsoft Exchange et en vérifiant que vous pouvez accéder aux informations de disponibilité Schedule+ d'un autre utilisateur et générer un Carnet d'adresses hors connexion), laissez le premier serveur hors réseau ou déconnecté, assurez-vous qu'il n'existe pas d'entrées dans le système WINS (Windows Internet Naming System) ou DNS (Domain Name System) pour le serveur que vous souhaitez supprimer, puis effectuez les procédures suivantes pour supprimer ce serveur du site de façon permanente :
À l'aide du programme Administrateur Exchange Server, cliquez sur le conteneur Configuration, puis sur le conteneur Serveurs.
Cliquez sur le premier serveur du site.
Dans le menu Edition, cliquez sur Supprimer ou appuyez sur SUPPR.
REMARQUE : Le Connecteur de disponibilité Microsoft Exchange Schedule+ n'est PAS déplacé automatiquement et est supprimé lors de la suppression du premier serveur du site. Si cela se produit, recréez cet objet en effectuant les procédures décrites dans l'article suivant de la Base de connaissances Microsoft :
148199 (http://support.microsoft.com/kb/148199/ ) XCLN : Procédures pour recréer un agent de disponibilité Schedule+ supprimé
Pour inclure les informations de disponibilité de Schedule+ :
Le dossier site Informations de disponibilité de Schedule+ est rempli lorsque les utilisateurs se connectent à Schedule+ et apportent des modifications. Pendant cette période, certaines informations de disponibilité des utilisateurs seront temporairement indisponibles.
Jusqu'à ce qu'un utilisateur ouvre une session et entre un rendez-vous (temps " non disponible "), il n'existera aucune information de disponibilité à afficher.
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft.
235898 (http://support.microsoft.com/kb/235898/ ) XADM : Impossible de générer le carnet d'adresses hors connexion
284148 (http://support.microsoft.com/kb/284148/ ) XADM : Comment faire pour supprimer le dernier ordinateur Exchange Server 5.5 d'un groupe administratif Exchange 2000
260781 (http://support.microsoft.com/kb/260781/ ) Le bouton de changement de mode est inactif dans la boîte de dialogue des propriétés de l'organisation après une mise à niveau de Exchange 5.5 Service Pack 3 vers Exchange 2000 Server
189286 (http://support.microsoft.com/kb/189286/ ) XADM : Comment faire pour supprimer un serveur d'un site
275171 (http://support.microsoft.com/kb/275171/ ) XADM : Comment faire pour redéfinir les dossiers système sur Exchange 2000 Server
822444 (http://support.microsoft.com/kb/822444/ ) Comment faire pour réinitialiser un dossier site dans Exchange Server 2003
--------------------------------------------------------------------------------
jeudi 1 octobre 2009
Exchange public folders replication
Ok : http://technet.microsoft.com/en-us/library/bb123619(EXCHG.65).aspx
double check :
http://www.msexchange.org/articles/Public-Folder-Replication-Troubleshooting.html
There are two main elements regarding public folders, namely the hierarchy and the content. To put it a basic way, the public folder structure that you see in Outlook is the hierarchy, whilst what’s actually stored in those folders is the content. Well, that’s fairly straightforward, so let’s get a bit more in-depth.
The first area to check when troubleshooting any public folder replication issues is the status of the hierarchy. For example, let’s say that you’ve installed a new Exchange server into an existing Exchange organization and you suspect that this new server has not been sent a copy of the hierarchy. In this case, the first thing you need to check is whether the public information store on the new server is correctly configured with an email address. Both public folder hierarchy and content changes are sent between Exchange servers via email messages, so it therefore follows that if the public information stores email each other, they’ll need an email address as well as a working email path between them. It’s the job of the Recipient Update Service (RUS) to ensure that objects are stamped with correct email addresses, and this includes the public information store. The first thing you should therefore check is the public information store’s email address which can be performed with ADSIEdit. You’ll find that ADSIEdit is installed as part of the Windows 2003 Support Tools.
With the ADSIEdit snap-in open, right-click ADSI Edit and choose the Connect to… option. In the resulting Connection Settings window, ensure that the naming context is set to Configuration and then click OK. This will then bind to the configuration naming context allowing you to navigate your way down to the public information store. You will therefore need to work your way down the tree accordingly:
CN=Configuration, DC=domain, DC=com
CN=Services
CN=Microsoft Exchange
CN={your Exchange organization name}
CN=Administrative Groups
CN={relevant administrative group}
CN=Servers
CN={relevant Exchange server}
CN=InformationStore
CN={relevant storage group}.
In the example in Figure 1 below, you can see that I’ve navigated my way down to the First Storage Group on the server DCEXCH1.
Figure 1: Public Store Location Using ADSIEdit
Now what you do is to right-click the public folder store shown in the right-hand pane and choose Properties from the context menu. In the resulting property window, find the proxyAddresses attribute and click the Edit button. This will bring up a similar window to the one shown below in Figure 2. Here you can see an example of a public information store that has been correctly stamped with both SMTP and X.400 email addresses; if there were no values in the proxyAddresses attribute, we’d instantly know that the RUS has not run against this store and would therefore need to start troubleshooting the RUS. Note that it’s the enterprise RUS and not the domain RUS that is responsible for stamping email addresses on system objects like the public information store, so make sure you’re looking at the correct one.
During my early migrations from Exchange 5.5 to Exchange 2000, I remember that one of the most common reasons for the RUS not stamping email addresses on new Exchange 2000 servers was due to a missing proxy address generator, such as those used by fax gateways for example. Other common reasons included invalid domain controllers or Exchange servers listed in the properties of the RUS. Check out the Links section at the end of this document for some useful links for troubleshooting RUS issues. One other thing worth noting is the format of the SMTP address assigned to the public store: servername-IS@domain.com. There will be more on the significance of this later in this article.
Figure 2: Public Store Email Addresses
I mentioned earlier that as far as public information stores are concerned, they need both an email address and a valid message path in order for the replication messages to be successfully sent and received. As far as the valid message path is concerned, note that it’s a good idea to check whether you have any transport links that disallow system messages. This check process can be made really easy by using the Winroute tool. For more information on using Winroute, see the Links section at the end of this article.
Replication Messages
Increasing the diagnostics logging level of your Exchange server is always useful when troubleshooting issues. Diagnostics logging levels can be set for the MSExchangeIS Public Folder object found on the properties of an Exchange server object in Exchange System Manager. In the case of public folder issues, I’ve seen many Microsoft PSS professionals in mailing lists and newsgroups recommended to set the diagnostics logging categories shown below in Table 1 on both the source and destination servers involved in the replication process. Doing so will allow you to get a clearer picture of what is happening during the replication process. For this article, we’re going to concentrate mainly on the replication incoming and outgoing categories.
Category
Logging Level
Replication AD Updates
Maximum
Replication Incoming Messages
Maximum
Replication Outgoing Messages
Maximum
Non-Delivery Reports
Maximum
Replication Backfill
Maximum
Replication General
Maximum
Replication Errors
Medium
Table 1: Recommended Diagnostics Logging Settings
Once logging has been set, the application event logs on both source and destination servers should then begin to produce more detailed information about the replication messages as and when those messages begin to flow. There are several different types of replication message. Table 2 below shows the message type, purpose, direction of message flow and additionally the associated event ID.
Type
Purpose
Direction
Event ID
0x2
Hierarchy Replication
Outgoing
3018
Incoming
3028
0x4
Content Replication
Outgoing
3020
Incoming
3030
0x8
Backfill Request
Outgoing
3014
Incoming
3024
0x80000002
0x80000004
Backfill Response (Hierarchy)
Backfill Response (Content)
Outgoing
3019
Incoming
3029
0x10
Status Replication
Outgoing
3017
Incoming
3027
0x20
Status Request
Outgoing
3017
Incoming
3027
Table 2: Message Types
Let’s take the first message type, the hierarchy replication message, as an example. If you create or delete a public folder, or perhaps change that folder’s permissions, a hierarchy replication message will be generated from the source server to the destination server. As you might expect, the sending of the hierarchy replication message maps to the Replication Outgoing Messages diagnostics logging category in Table 1 above, whilst the receiving of the hierarchy replication message maps to the Replication Incoming Messages category. It therefore follows that for each outgoing message from the source server, there should be a corresponding incoming message on the destination server.
Consider the example replication message shown below in Figure 3. Here you can see that the event category is shown as Replication Outgoing Message. The reason for this message is clear when you examine the event details. The Type is set to 0x2 (hierarchy) and the affected folder is called New Test Folder; this was a new public folder that I had created.
Figure 3: Outgoing Replication Message Event
As I just mentioned, it is normal to expect to see a corresponding incoming replication message on the destination server. Therefore, if you were troubleshooting a situation where Outlook clients connected to the destination server were not displaying the New Test Folder public folder, the next step would be to examine the event log on the destination server for the corresponding incoming message event to make sure it had been received. This event would have a category of Replication Incoming Message and an event ID of 3028. You would expect the event description to again list a message type of 0x2, since this would be a hierarchy message, and also to contain the folder name of New Test Folder.
Naturally the same process applies to the other types of replication message. For example, if a user posts a new message to a pubic folder, or perhaps modifies an existing post in some way and saves it back to the public folder, the entire post is replicated and will be seen in the event viewer as a content replication message (type 0x4) with event IDs 3020 or 3030 depending on whether you are examining the source or destination server.
Backfill request and response messages are part of the backfill process which itself is the process whereby public stores that detect they are missing some replication updates re-request these updates from other public stores. The backfill request is sent as message type 0x8, whilst the response message will be type 0x80000002 for hierarchy messages and 0x80000004 for content messages. Figure 4 below shows an example of a content backfill response message. In this example, server DCEXCH1 is responding to server EXCH3’s backfill request for the public folder called Items For Sale.
Figure 4: Content Backfill Response Replication Message Event
The final replication message types are status replication, type 0x10, and status request, type 0x20. These are used by the public information stores to allow the receiving store to ascertain as to whether it is synchronized with the sending store.
Tracking Replication Messages
Continuing with our example scenario above, it may be the case that the destination server did not contain the corresponding incoming replication message event. If this proved to be the situation, the next logical step would be to examine the message transport. Probably the first thing to do would be to use the Message Tracking Center in Exchange System Manager in an attempt to see what is happening.
You can see from Figure 5 below that I’ve tracked messages sent from the public folder store on server DCEXCH1. To do this, I simply typed in dcexch1-is@hobsonlabs.com as the sender of the message. You’ll recall from earlier in this article that this is the SMTP address of the sending public information store; you can see that this has been resolved to the friendly display name of Public Folder Store (DCEXCH1).
Figure 5: Tracking Public Folder Replication Messages
I personally find it very useful to ensure that subject logging is enabled within message tracking. You can enable this on the General tab of the properties of your Exchange server object in Exchange System Manager. You can see from Figure 5 above that enabling subject logging makes finding your messages much easier, since all messages after 22:33 have the subject field populated after subject logging was enabled. For example, it can clearly be seen that the message sent at 22:45 is a hierarchy replication message.
To drill deeper into the events associated with each tracked message, it is simply a case of double-clicking the relevant tracked message. For example, double-clicking the hierarchy message sent at 23:00 reveals the Message History screen as shown below in Figure 6. Here we can see that the last entry shows us that the message has been successfully delivered to the destination server EXCH3. Had the last two entries on this screen not been present, we would have seen that the last line would have stated SMTP: Message Routed and Queued for Remote Delivery. In this case, we would have known that the message had likely queued on our source server and hence had not been delivered. It would have then been time to check the message queues using the Queue Viewer utility in Exchange System Manager on the source server.
Figure 6: Message Tracking History
One last thing to note here is that a single replication message is created even if there are multiple replicas of that public folder. For example, if a public folder is modified on server DCEXCH1 and a replica of that folder exists on both the servers EXCH2 and EXCH3, you will find that only a single replication message is generated and is addressed to both public folder stores at the same time. Naturally when tracking such a message, expect the Message History window to show this as shown below in Figure 7.
Figure 7: Message Tracking History – Multiple Replicas
Summary
The most important thing to remember about public folder replication is that it’s message-based replication. Knowing this means that, once you’re confident that the public stores have correct email addresses, you can use standard tools in the form of Exchange System Manager and the Event Viewer to start troubleshooting your replication issues. Of course, there are always more complex issues that could arise that are way beyond the scope of this article, but hopefully this article has given you a starting point.
Links
Troubleshooting the Recipient Update Service
http://support.microsoft.com/?id=288807
Troubleshooting the RUS Using Event Logs Parts 1-4
http://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx
http://blogs.technet.com/exchange/archive/2004/07/15/184356.aspx
http://blogs.technet.com/exchange/archive/2004/07/22/191513.aspx
http://blogs.technet.com/exchange/archive/0001/01/01/198662.aspx
Using Winroute to Determine The Routing Status of Your Exchange Organization
http://www.msexchange.org/tutorials/WinRoute-Routing-status-Exchange-organization.html
double check :
http://www.msexchange.org/articles/Public-Folder-Replication-Troubleshooting.html
There are two main elements regarding public folders, namely the hierarchy and the content. To put it a basic way, the public folder structure that you see in Outlook is the hierarchy, whilst what’s actually stored in those folders is the content. Well, that’s fairly straightforward, so let’s get a bit more in-depth.
The first area to check when troubleshooting any public folder replication issues is the status of the hierarchy. For example, let’s say that you’ve installed a new Exchange server into an existing Exchange organization and you suspect that this new server has not been sent a copy of the hierarchy. In this case, the first thing you need to check is whether the public information store on the new server is correctly configured with an email address. Both public folder hierarchy and content changes are sent between Exchange servers via email messages, so it therefore follows that if the public information stores email each other, they’ll need an email address as well as a working email path between them. It’s the job of the Recipient Update Service (RUS) to ensure that objects are stamped with correct email addresses, and this includes the public information store. The first thing you should therefore check is the public information store’s email address which can be performed with ADSIEdit. You’ll find that ADSIEdit is installed as part of the Windows 2003 Support Tools.
With the ADSIEdit snap-in open, right-click ADSI Edit and choose the Connect to… option. In the resulting Connection Settings window, ensure that the naming context is set to Configuration and then click OK. This will then bind to the configuration naming context allowing you to navigate your way down to the public information store. You will therefore need to work your way down the tree accordingly:
CN=Configuration, DC=domain, DC=com
CN=Services
CN=Microsoft Exchange
CN={your Exchange organization name}
CN=Administrative Groups
CN={relevant administrative group}
CN=Servers
CN={relevant Exchange server}
CN=InformationStore
CN={relevant storage group}.
In the example in Figure 1 below, you can see that I’ve navigated my way down to the First Storage Group on the server DCEXCH1.
Figure 1: Public Store Location Using ADSIEdit
Now what you do is to right-click the public folder store shown in the right-hand pane and choose Properties from the context menu. In the resulting property window, find the proxyAddresses attribute and click the Edit button. This will bring up a similar window to the one shown below in Figure 2. Here you can see an example of a public information store that has been correctly stamped with both SMTP and X.400 email addresses; if there were no values in the proxyAddresses attribute, we’d instantly know that the RUS has not run against this store and would therefore need to start troubleshooting the RUS. Note that it’s the enterprise RUS and not the domain RUS that is responsible for stamping email addresses on system objects like the public information store, so make sure you’re looking at the correct one.
During my early migrations from Exchange 5.5 to Exchange 2000, I remember that one of the most common reasons for the RUS not stamping email addresses on new Exchange 2000 servers was due to a missing proxy address generator, such as those used by fax gateways for example. Other common reasons included invalid domain controllers or Exchange servers listed in the properties of the RUS. Check out the Links section at the end of this document for some useful links for troubleshooting RUS issues. One other thing worth noting is the format of the SMTP address assigned to the public store: servername-IS@domain.com. There will be more on the significance of this later in this article.
Figure 2: Public Store Email Addresses
I mentioned earlier that as far as public information stores are concerned, they need both an email address and a valid message path in order for the replication messages to be successfully sent and received. As far as the valid message path is concerned, note that it’s a good idea to check whether you have any transport links that disallow system messages. This check process can be made really easy by using the Winroute tool. For more information on using Winroute, see the Links section at the end of this article.
Replication Messages
Increasing the diagnostics logging level of your Exchange server is always useful when troubleshooting issues. Diagnostics logging levels can be set for the MSExchangeIS Public Folder object found on the properties of an Exchange server object in Exchange System Manager. In the case of public folder issues, I’ve seen many Microsoft PSS professionals in mailing lists and newsgroups recommended to set the diagnostics logging categories shown below in Table 1 on both the source and destination servers involved in the replication process. Doing so will allow you to get a clearer picture of what is happening during the replication process. For this article, we’re going to concentrate mainly on the replication incoming and outgoing categories.
Category
Logging Level
Replication AD Updates
Maximum
Replication Incoming Messages
Maximum
Replication Outgoing Messages
Maximum
Non-Delivery Reports
Maximum
Replication Backfill
Maximum
Replication General
Maximum
Replication Errors
Medium
Table 1: Recommended Diagnostics Logging Settings
Once logging has been set, the application event logs on both source and destination servers should then begin to produce more detailed information about the replication messages as and when those messages begin to flow. There are several different types of replication message. Table 2 below shows the message type, purpose, direction of message flow and additionally the associated event ID.
Type
Purpose
Direction
Event ID
0x2
Hierarchy Replication
Outgoing
3018
Incoming
3028
0x4
Content Replication
Outgoing
3020
Incoming
3030
0x8
Backfill Request
Outgoing
3014
Incoming
3024
0x80000002
0x80000004
Backfill Response (Hierarchy)
Backfill Response (Content)
Outgoing
3019
Incoming
3029
0x10
Status Replication
Outgoing
3017
Incoming
3027
0x20
Status Request
Outgoing
3017
Incoming
3027
Table 2: Message Types
Let’s take the first message type, the hierarchy replication message, as an example. If you create or delete a public folder, or perhaps change that folder’s permissions, a hierarchy replication message will be generated from the source server to the destination server. As you might expect, the sending of the hierarchy replication message maps to the Replication Outgoing Messages diagnostics logging category in Table 1 above, whilst the receiving of the hierarchy replication message maps to the Replication Incoming Messages category. It therefore follows that for each outgoing message from the source server, there should be a corresponding incoming message on the destination server.
Consider the example replication message shown below in Figure 3. Here you can see that the event category is shown as Replication Outgoing Message. The reason for this message is clear when you examine the event details. The Type is set to 0x2 (hierarchy) and the affected folder is called New Test Folder; this was a new public folder that I had created.
Figure 3: Outgoing Replication Message Event
As I just mentioned, it is normal to expect to see a corresponding incoming replication message on the destination server. Therefore, if you were troubleshooting a situation where Outlook clients connected to the destination server were not displaying the New Test Folder public folder, the next step would be to examine the event log on the destination server for the corresponding incoming message event to make sure it had been received. This event would have a category of Replication Incoming Message and an event ID of 3028. You would expect the event description to again list a message type of 0x2, since this would be a hierarchy message, and also to contain the folder name of New Test Folder.
Naturally the same process applies to the other types of replication message. For example, if a user posts a new message to a pubic folder, or perhaps modifies an existing post in some way and saves it back to the public folder, the entire post is replicated and will be seen in the event viewer as a content replication message (type 0x4) with event IDs 3020 or 3030 depending on whether you are examining the source or destination server.
Backfill request and response messages are part of the backfill process which itself is the process whereby public stores that detect they are missing some replication updates re-request these updates from other public stores. The backfill request is sent as message type 0x8, whilst the response message will be type 0x80000002 for hierarchy messages and 0x80000004 for content messages. Figure 4 below shows an example of a content backfill response message. In this example, server DCEXCH1 is responding to server EXCH3’s backfill request for the public folder called Items For Sale.
Figure 4: Content Backfill Response Replication Message Event
The final replication message types are status replication, type 0x10, and status request, type 0x20. These are used by the public information stores to allow the receiving store to ascertain as to whether it is synchronized with the sending store.
Tracking Replication Messages
Continuing with our example scenario above, it may be the case that the destination server did not contain the corresponding incoming replication message event. If this proved to be the situation, the next logical step would be to examine the message transport. Probably the first thing to do would be to use the Message Tracking Center in Exchange System Manager in an attempt to see what is happening.
You can see from Figure 5 below that I’ve tracked messages sent from the public folder store on server DCEXCH1. To do this, I simply typed in dcexch1-is@hobsonlabs.com as the sender of the message. You’ll recall from earlier in this article that this is the SMTP address of the sending public information store; you can see that this has been resolved to the friendly display name of Public Folder Store (DCEXCH1).
Figure 5: Tracking Public Folder Replication Messages
I personally find it very useful to ensure that subject logging is enabled within message tracking. You can enable this on the General tab of the properties of your Exchange server object in Exchange System Manager. You can see from Figure 5 above that enabling subject logging makes finding your messages much easier, since all messages after 22:33 have the subject field populated after subject logging was enabled. For example, it can clearly be seen that the message sent at 22:45 is a hierarchy replication message.
To drill deeper into the events associated with each tracked message, it is simply a case of double-clicking the relevant tracked message. For example, double-clicking the hierarchy message sent at 23:00 reveals the Message History screen as shown below in Figure 6. Here we can see that the last entry shows us that the message has been successfully delivered to the destination server EXCH3. Had the last two entries on this screen not been present, we would have seen that the last line would have stated SMTP: Message Routed and Queued for Remote Delivery. In this case, we would have known that the message had likely queued on our source server and hence had not been delivered. It would have then been time to check the message queues using the Queue Viewer utility in Exchange System Manager on the source server.
Figure 6: Message Tracking History
One last thing to note here is that a single replication message is created even if there are multiple replicas of that public folder. For example, if a public folder is modified on server DCEXCH1 and a replica of that folder exists on both the servers EXCH2 and EXCH3, you will find that only a single replication message is generated and is addressed to both public folder stores at the same time. Naturally when tracking such a message, expect the Message History window to show this as shown below in Figure 7.
Figure 7: Message Tracking History – Multiple Replicas
Summary
The most important thing to remember about public folder replication is that it’s message-based replication. Knowing this means that, once you’re confident that the public stores have correct email addresses, you can use standard tools in the form of Exchange System Manager and the Event Viewer to start troubleshooting your replication issues. Of course, there are always more complex issues that could arise that are way beyond the scope of this article, but hopefully this article has given you a starting point.
Links
Troubleshooting the Recipient Update Service
http://support.microsoft.com/?id=288807
Troubleshooting the RUS Using Event Logs Parts 1-4
http://blogs.technet.com/exchange/archive/2004/07/07/175444.aspx
http://blogs.technet.com/exchange/archive/2004/07/15/184356.aspx
http://blogs.technet.com/exchange/archive/2004/07/22/191513.aspx
http://blogs.technet.com/exchange/archive/0001/01/01/198662.aspx
Using Winroute to Determine The Routing Status of Your Exchange Organization
http://www.msexchange.org/tutorials/WinRoute-Routing-status-Exchange-organization.html
Pour transférer Exchange 2003 sur un nouveau matériel tout en conservant le même nom de serveur
http://technet.microsoft.com/fr-fr/library/aa997176(EXCHG.65).aspx
Comment activer la fonction global catalogue
http://books.google.ca/books?id=b2RFudWRUkYC&pg=PA380&lpg=PA380&dq=Activer+la+fonction+global+catalogue&source=bl&ots=M3nnLG-IxI&sig=NuKMGord7kWZHFsDBl_eGaCRxIk&hl=fr&ei=IK_ESufMCMbDlAeK6qiSAw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CAwQ6AEwAg#v=onepage&q=Activer%20la%20fonction%20global%20catalogue&f=false
Comment faire pour installer et configurer un serveur DNS dans Windows Server 2003
http://support.microsoft.com/kb/814591
Cet article décrit étape par étape comment installer et configurer DNS sur votre ordinateur Windows Server 2003.
Retour au début
Avant de commencer
Avant de démarrer la configuration de votre DNS, vous devez collecter certaines informations de base. Certaines de ces informations doivent être approuvées par Internic pour une utilisation sur Internet, mais si vous configurez le serveur en vue d'une utilisation exclusivement interne, vous pouvez choisir les noms et les adresses IP à utiliser.
Vous devez posséder les informations suivantes :
votre nom de domaine (approuvé par Internic) ;
l'adresse IP et le nom d'hôte de chaque serveur pour lequel vous souhaitez fournir une résolution de noms.
Remarque : les serveurs peuvent être vos serveurs de messagerie, des serveurs d'accès public, des serveurs FTP ou WWW, etc.
Avant de configurer votre ordinateur en tant que serveur DNS, vérifiez que les conditions suivantes sont remplies :
Votre système d'exploitation est configuré correctement. Dans la famille Windows Server 2003, le service DNS dépend de la configuration correcte du système d'exploitation et de ses services, tels que TCP/IP. Si votre système d'exploitation Windows Server 2003 est une nouvelle installation, vous pouvez utiliser les paramètres de service par défaut. Aucune autre action n'est nécessaire.
Vous avez alloué tout l'espace disque disponible.
Tous les volumes de disque existants utilisent le système de fichiers NTFS. Les volumes FAT32 ne sont pas sécurisés, et ils ne prennent pas en charge la compression de fichiers et de dossiers, les quotas de disque, le chiffrement de fichiers ou les autorisations individuelles d'accès aux fichiers.
Retour au début
Installation du serveur DNS
Démarrez l'Assistant Composants de Windows. Pour cela, procédez comme suit :
Cliquez sur Démarrer, sur Panneau de configuration, puis sur Ajout/Suppression de programmes.
Cliquez sur Ajouter ou supprimer des composants Windows.
Sous Composants, activez la case à cocher Services de mise en réseau, puis cliquez sur Détails.
Dans Sous-composants de Services de mise en réseau, activez la case à cocher Système DNS (Domain Name System), cliquez sur OK, puis cliquez sur Suivant.
Si vous y êtes invité, dans Copier les fichiers à partir de :, tapez le chemin d'accès complet des fichiers de distribution, puis cliquez sur OK.
Retour au début
Configuration du serveur DNS
Démarrez l'Assistant Configurer votre serveur. Pour cela, cliquez sur Démarrer, pointez sur Tous les programmes, sur Outils d'administration, puis cliquez sur Assistant Configurer votre serveur.
Sur la page Rôle du serveur, cliquez sur Serveur DNS, puis sur Suivant.
Sur la page Aperçu des sélections, consultez et vérifiez les options que vous avez sélectionnées. Les éléments suivants doivent apparaître dans cette page :
Installer un serveur DNS
Exécutez l'Assistant Configurer un serveur DNS pour configurer un serveur DNS
Si la page Aperçu des sélections contient ces deux éléments, cliquez sur Suivant. Si la page Aperçu des sélections ne comporte pas ces deux éléments, cliquez sur Précédent pour retourner à la page Rôle du serveur, cliquez sur DNS, puis cliquez sur Suivant.
Lorsque l'Assistant Configurer votre serveur installe le service DNS, il détermine en premier si l'adresse IP de ce serveur est statique ou configurée automatiquement. Si votre serveur est configuré actuellement de manière à obtenir automatiquement son adresse IP, la page Configuration des composants de l'Assistant Composants de Windows vous invite à configurer ce serveur avec une adresse IP statique. Pour cela, procédez comme suit :
Dans la boîte de dialogue Propriétés de Connexion au réseau local, cliquez sur Protocole Internet (TCP/IP) puis sur Propriétés.
Dans la boîte de dialogue Propriétés du protocole Internet (TCP/IP), cliquez sur Utiliser l'adresse IP suivante, puis tapez l'adresse IP statique, le masque de sous-réseau et la passerelle par défaut pour ce serveur.
Dans Serveur DNS préféré, tapez l'adresse IP de ce serveur.
Dans Serveur DNS auxiliaire, tapez l'adresse IP d'un autre serveur DNS interne ou laissez cette zone vide.
Lorsque vous terminez la configuration des adresses statiques pour votre serveur DNS, cliquez sur OK, puis cliquez sur Fermer.
Après avoir cliqué sur Fermer, l'Assistant Configuration d'un serveur DNS démarre. Dans l'Assistant, procédez comme suit :
Sur la page Sélectionnez une action de configuration, activez la case à cocher Créer une zone de recherche directe, puis cliquez sur Suivant.
Pour spécifier que ce serveur DNS héberge une zone DNS qui contient des enregistrements de ressource DNS pour vos ressources réseau, sur la page Emplacement du serveur principal, cliquez sur Ce serveur assure la maintenance de la zone, puis cliquez sur Suivant.
Sur la page Nom de la zone, dans Nom de la zone, spécifiez le nom de la zone DNS de votre réseau, puis cliquez sur Suivant. Le nom de la zone est identique au nom du domaine DNS de votre petite organisation ou de votre filiale.
Sur la page Mise à niveau dynamique, cliquez sur Autoriser à la fois les mises à jour dynamiques sécurisées et non sécurisées, puis cliquez sur Suivant. Cela garantit que les enregistrements de ressource DNS pour les ressources de votre réseau se mettent à jour automatiquement.
Sur la page Redirecteurs, cliquez sur Oui, il doit rediriger les requêtes vers les serveurs DNS ayant les adresses IP suivantes, puis cliquez sur Suivant. Lorsque vous sélectionnez cette configuration, vous transférez toutes les requêtes DNS de noms DNS à l'extérieur de votre réseau vers un serveur DNS vers votre fournisseur de services Internet ou votre bureau central. Tapez une ou plusieurs adresses IP utilisées par votre fournisseur de services Internet ou votre bureau central.
Sur la page Fin de l'Assistant Configuration d'un serveur DNS de l'Assistant Configuration d'un serveur DNS, vous pouvez cliquer sur Précédent pour modifier des paramètres. Pour appliquer vos sélections, cliquez sur Terminer.
À la fin de l'Assistant Configuration d'un serveur DNS, l'Assistant Configurer votre serveur affiche la page Ce serveur est maintenant un serveur DNS. Pour revoir toutes les modifications que vous avez apportées à votre serveur dans l'Assistant Configurer votre serveur ou pour vous assurer que le nouveau rôle a été installé avec succès, cliquez sur journal Configuration de votre serveur. Le journal de l'Assistant Configurer votre serveur se trouve dans %systemroot%\Debug\Configure Your Server.log. Pour fermer l'Assistant Configurer votre serveur, cliquez sur Terminer.
Cet article décrit étape par étape comment installer et configurer DNS sur votre ordinateur Windows Server 2003.
Retour au début
Avant de commencer
Avant de démarrer la configuration de votre DNS, vous devez collecter certaines informations de base. Certaines de ces informations doivent être approuvées par Internic pour une utilisation sur Internet, mais si vous configurez le serveur en vue d'une utilisation exclusivement interne, vous pouvez choisir les noms et les adresses IP à utiliser.
Vous devez posséder les informations suivantes :
votre nom de domaine (approuvé par Internic) ;
l'adresse IP et le nom d'hôte de chaque serveur pour lequel vous souhaitez fournir une résolution de noms.
Remarque : les serveurs peuvent être vos serveurs de messagerie, des serveurs d'accès public, des serveurs FTP ou WWW, etc.
Avant de configurer votre ordinateur en tant que serveur DNS, vérifiez que les conditions suivantes sont remplies :
Votre système d'exploitation est configuré correctement. Dans la famille Windows Server 2003, le service DNS dépend de la configuration correcte du système d'exploitation et de ses services, tels que TCP/IP. Si votre système d'exploitation Windows Server 2003 est une nouvelle installation, vous pouvez utiliser les paramètres de service par défaut. Aucune autre action n'est nécessaire.
Vous avez alloué tout l'espace disque disponible.
Tous les volumes de disque existants utilisent le système de fichiers NTFS. Les volumes FAT32 ne sont pas sécurisés, et ils ne prennent pas en charge la compression de fichiers et de dossiers, les quotas de disque, le chiffrement de fichiers ou les autorisations individuelles d'accès aux fichiers.
Retour au début
Installation du serveur DNS
Démarrez l'Assistant Composants de Windows. Pour cela, procédez comme suit :
Cliquez sur Démarrer, sur Panneau de configuration, puis sur Ajout/Suppression de programmes.
Cliquez sur Ajouter ou supprimer des composants Windows.
Sous Composants, activez la case à cocher Services de mise en réseau, puis cliquez sur Détails.
Dans Sous-composants de Services de mise en réseau, activez la case à cocher Système DNS (Domain Name System), cliquez sur OK, puis cliquez sur Suivant.
Si vous y êtes invité, dans Copier les fichiers à partir de :, tapez le chemin d'accès complet des fichiers de distribution, puis cliquez sur OK.
Retour au début
Configuration du serveur DNS
Démarrez l'Assistant Configurer votre serveur. Pour cela, cliquez sur Démarrer, pointez sur Tous les programmes, sur Outils d'administration, puis cliquez sur Assistant Configurer votre serveur.
Sur la page Rôle du serveur, cliquez sur Serveur DNS, puis sur Suivant.
Sur la page Aperçu des sélections, consultez et vérifiez les options que vous avez sélectionnées. Les éléments suivants doivent apparaître dans cette page :
Installer un serveur DNS
Exécutez l'Assistant Configurer un serveur DNS pour configurer un serveur DNS
Si la page Aperçu des sélections contient ces deux éléments, cliquez sur Suivant. Si la page Aperçu des sélections ne comporte pas ces deux éléments, cliquez sur Précédent pour retourner à la page Rôle du serveur, cliquez sur DNS, puis cliquez sur Suivant.
Lorsque l'Assistant Configurer votre serveur installe le service DNS, il détermine en premier si l'adresse IP de ce serveur est statique ou configurée automatiquement. Si votre serveur est configuré actuellement de manière à obtenir automatiquement son adresse IP, la page Configuration des composants de l'Assistant Composants de Windows vous invite à configurer ce serveur avec une adresse IP statique. Pour cela, procédez comme suit :
Dans la boîte de dialogue Propriétés de Connexion au réseau local, cliquez sur Protocole Internet (TCP/IP) puis sur Propriétés.
Dans la boîte de dialogue Propriétés du protocole Internet (TCP/IP), cliquez sur Utiliser l'adresse IP suivante, puis tapez l'adresse IP statique, le masque de sous-réseau et la passerelle par défaut pour ce serveur.
Dans Serveur DNS préféré, tapez l'adresse IP de ce serveur.
Dans Serveur DNS auxiliaire, tapez l'adresse IP d'un autre serveur DNS interne ou laissez cette zone vide.
Lorsque vous terminez la configuration des adresses statiques pour votre serveur DNS, cliquez sur OK, puis cliquez sur Fermer.
Après avoir cliqué sur Fermer, l'Assistant Configuration d'un serveur DNS démarre. Dans l'Assistant, procédez comme suit :
Sur la page Sélectionnez une action de configuration, activez la case à cocher Créer une zone de recherche directe, puis cliquez sur Suivant.
Pour spécifier que ce serveur DNS héberge une zone DNS qui contient des enregistrements de ressource DNS pour vos ressources réseau, sur la page Emplacement du serveur principal, cliquez sur Ce serveur assure la maintenance de la zone, puis cliquez sur Suivant.
Sur la page Nom de la zone, dans Nom de la zone, spécifiez le nom de la zone DNS de votre réseau, puis cliquez sur Suivant. Le nom de la zone est identique au nom du domaine DNS de votre petite organisation ou de votre filiale.
Sur la page Mise à niveau dynamique, cliquez sur Autoriser à la fois les mises à jour dynamiques sécurisées et non sécurisées, puis cliquez sur Suivant. Cela garantit que les enregistrements de ressource DNS pour les ressources de votre réseau se mettent à jour automatiquement.
Sur la page Redirecteurs, cliquez sur Oui, il doit rediriger les requêtes vers les serveurs DNS ayant les adresses IP suivantes, puis cliquez sur Suivant. Lorsque vous sélectionnez cette configuration, vous transférez toutes les requêtes DNS de noms DNS à l'extérieur de votre réseau vers un serveur DNS vers votre fournisseur de services Internet ou votre bureau central. Tapez une ou plusieurs adresses IP utilisées par votre fournisseur de services Internet ou votre bureau central.
Sur la page Fin de l'Assistant Configuration d'un serveur DNS de l'Assistant Configuration d'un serveur DNS, vous pouvez cliquer sur Précédent pour modifier des paramètres. Pour appliquer vos sélections, cliquez sur Terminer.
À la fin de l'Assistant Configuration d'un serveur DNS, l'Assistant Configurer votre serveur affiche la page Ce serveur est maintenant un serveur DNS. Pour revoir toutes les modifications que vous avez apportées à votre serveur dans l'Assistant Configurer votre serveur ou pour vous assurer que le nouveau rôle a été installé avec succès, cliquez sur journal Configuration de votre serveur. Le journal de l'Assistant Configurer votre serveur se trouve dans %systemroot%\Debug\Configure Your Server.log. Pour fermer l'Assistant Configurer votre serveur, cliquez sur Terminer.
Tranfert AD et Exhange vers un nouveau serveur!
AD :
http://www.laboratoire-microsoft.org/articles/win/migration_AD_materiel/0/
Exchange :
http://www.generation-nt.com/divers/click.php?url=UjlSJQMlVXdYbVR7VntdLABkCGMNZVA4CmAEIQMuAGlSOARkVXVVaFomVTpXMwJzUH9ZMl4xVT5dfVBnUiMBKFI3UiMDflVrWD5UNlYmXTkAcwh5DSJQNwpkBGwDOQAzUmAEMFUx
http://www.laboratoire-microsoft.org/articles/win/migration_AD_materiel/0/
Exchange :
http://www.generation-nt.com/divers/click.php?url=UjlSJQMlVXdYbVR7VntdLABkCGMNZVA4CmAEIQMuAGlSOARkVXVVaFomVTpXMwJzUH9ZMl4xVT5dfVBnUiMBKFI3UiMDflVrWD5UNlYmXTkAcwh5DSJQNwpkBGwDOQAzUmAEMFUx
Configuring an exchange SMTP Connector
http://www.msexchange.org/tutorials/Configuring-SMTP-Connector.html
This article is based on Windows 2003 Enterprise Edition (Build 3790) and Microsoft Exchange Server 2003 (Build 6944.4).
Introduction
There are many ways in Exchange 2003 to configure your organization for receiving and sending e-mails. The default Virtual SMTP Server created in every Exchange Organization is good enough to connect the entire organization to the Internet. The virtual Server handles these connections. Generally, all that you require for mail to flow is the connectivity to the Internet and an MX record that points back to the server that is running Exchange 2000 or Exchange 2003 in your organization.
The question is: Why do we need a SMTP Connector?
The answer:
You are connecting to a Microsoft Exchange Server 5.5 computer in another routing group (site), and want to use SMTP.
You want to configure either server-side or client-side ETRN/TURN.
You want either to send or not to send ETRN/TURN.
You want to request ETRN/TURN when sending messages.
You want to request ETRN/TURN from different servers.
You want to configure outbound security, and to do it once and affect many outbound servers.
You want to permit high, normal, or low message priorities for a domain.
You want to permit system or non-system messages.
You want to schedule the SMTP connector.
You want to use different delivery times for oversized messages.
You want to queue mail for remote triggered delivery.
You want to send HELO instead of EHLO.
You want to specify a specific address space.
You want to set delivery restrictions.
An SMTP connector requires an SMTP virtual server. Settings on the SMTP connector override are comparable to settings on the virtual server. When you restrict the size of messages on the virtual server, any connector automatically inherits that limit.
Let’s begin
The first step is to open the Exchange System Manager (ESM) and navigate to the Connectors Container in the First Administrative Group in this example. When you can’t see the Administrative Groups you have to go into the properties of the Exchange Organization object and enable the view of “Administrative Groups” and “Routing Groups”.
Important: Unless you activate the view of Routing- and Administrative Groups in ESM you can’t create a Routing Group Connector. This is also true when your Administrative Group has only one Routing Group.
In the Context Menu of the Connector Container click New – “SMTP Connector”.
Figure 1: Creating a SMTP Connector
Now we have to give a Name to the new Connection. I recommend naming the connector after the two endpoints which this connector connects.
Next we have to select “Use DNS to route to each address space on this connector”. DNS is the recommended configuration for Exchange.
It is also possible to “Forward all mail through this connector to the following smart hosts”. When you prefer this type you must type the host name into the field or the IP address of the Smart Host in Brackets (this prevents Exchange from trying to resolve the IP Address with DNS).
Figure 2: General settings
Select a Bridgehead Server for the virtual SMTP Server Instance. Every SMTP Connector must be associated with a virtual SMTP Server instance.
Figure 3: Select a Bridgehead Serve
The next step is to configure a Address Space for the SMTP Connector. There a several Address Space types available. We select “SMTP” and specify the Address “contoso.com”. In the future this connector will accept e-mails for *@contoso.com. You can use wildcards like *.com and many others.
The Connector scope makes it possible for you to restrict the scope of the selected Routing Group or the entire Organization.
To optimize and customize the Exchange Routing process you can assign logical costs to every address space.
Figure 4: Select a Address Space
In the Delivery Restrictions field you can specify from which Recipients you accept and reject messages. You can specify “Black-" and "White-Lists".
Figure 5: Configure Delivery Restrictions
In the Delivery Options Field you can specify when messages are sent through this connector.
A nice feature is to specify a different delivery time for oversize messages.
Figure 6: Configure Delivery Options
In the Content Restrictions field you can select the allowed priorities for e-mails sent through this connector. You can specify a message Priority in Outlook.
It is possible to choose which allowed types of message are delivered through this connector. This makes it possible to create two connectors. One connector for only Non-system messages and one connector for System messages for a better control of message delivery.
At last you can restrict the maximum message size for this connector.
Figure 7: Configure Content Restrictions
In the Advanced Tab you can configure the SMTP Connector for the extended SMTP commands (HELO/EHLO). The Default is EHLO. Older e-mail Systems don’t understand the EHLO syntax and use HELO instead of EHLO.
Figure 8: Configure Advanced Options
Conclusion
With the help of an SMTP Connector you have complete control over the message flow in your Enterprise. The SMTP Connector is a flexible and powerful component in an Exchange Organization.
Related Links
Exchange 2003 Online help
www.microsoft.com/exchange
http://support.microsoft.com/default.aspx?scid=kb;en-us;314961
http://support.microsoft.com/default.aspx?scid=kb;en-us;265293
http://support.microsoft.com/default.aspx?scid=kb;en-us;294736
This article is based on Windows 2003 Enterprise Edition (Build 3790) and Microsoft Exchange Server 2003 (Build 6944.4).
Introduction
There are many ways in Exchange 2003 to configure your organization for receiving and sending e-mails. The default Virtual SMTP Server created in every Exchange Organization is good enough to connect the entire organization to the Internet. The virtual Server handles these connections. Generally, all that you require for mail to flow is the connectivity to the Internet and an MX record that points back to the server that is running Exchange 2000 or Exchange 2003 in your organization.
The question is: Why do we need a SMTP Connector?
The answer:
You are connecting to a Microsoft Exchange Server 5.5 computer in another routing group (site), and want to use SMTP.
You want to configure either server-side or client-side ETRN/TURN.
You want either to send or not to send ETRN/TURN.
You want to request ETRN/TURN when sending messages.
You want to request ETRN/TURN from different servers.
You want to configure outbound security, and to do it once and affect many outbound servers.
You want to permit high, normal, or low message priorities for a domain.
You want to permit system or non-system messages.
You want to schedule the SMTP connector.
You want to use different delivery times for oversized messages.
You want to queue mail for remote triggered delivery.
You want to send HELO instead of EHLO.
You want to specify a specific address space.
You want to set delivery restrictions.
An SMTP connector requires an SMTP virtual server. Settings on the SMTP connector override are comparable to settings on the virtual server. When you restrict the size of messages on the virtual server, any connector automatically inherits that limit.
Let’s begin
The first step is to open the Exchange System Manager (ESM) and navigate to the Connectors Container in the First Administrative Group in this example. When you can’t see the Administrative Groups you have to go into the properties of the Exchange Organization object and enable the view of “Administrative Groups” and “Routing Groups”.
Important: Unless you activate the view of Routing- and Administrative Groups in ESM you can’t create a Routing Group Connector. This is also true when your Administrative Group has only one Routing Group.
In the Context Menu of the Connector Container click New – “SMTP Connector”.
Figure 1: Creating a SMTP Connector
Now we have to give a Name to the new Connection. I recommend naming the connector after the two endpoints which this connector connects.
Next we have to select “Use DNS to route to each address space on this connector”. DNS is the recommended configuration for Exchange.
It is also possible to “Forward all mail through this connector to the following smart hosts”. When you prefer this type you must type the host name into the field or the IP address of the Smart Host in Brackets (this prevents Exchange from trying to resolve the IP Address with DNS).
Figure 2: General settings
Select a Bridgehead Server for the virtual SMTP Server Instance. Every SMTP Connector must be associated with a virtual SMTP Server instance.
Figure 3: Select a Bridgehead Serve
The next step is to configure a Address Space for the SMTP Connector. There a several Address Space types available. We select “SMTP” and specify the Address “contoso.com”. In the future this connector will accept e-mails for *@contoso.com. You can use wildcards like *.com and many others.
The Connector scope makes it possible for you to restrict the scope of the selected Routing Group or the entire Organization.
To optimize and customize the Exchange Routing process you can assign logical costs to every address space.
Figure 4: Select a Address Space
In the Delivery Restrictions field you can specify from which Recipients you accept and reject messages. You can specify “Black-" and "White-Lists".
Figure 5: Configure Delivery Restrictions
In the Delivery Options Field you can specify when messages are sent through this connector.
A nice feature is to specify a different delivery time for oversize messages.
Figure 6: Configure Delivery Options
In the Content Restrictions field you can select the allowed priorities for e-mails sent through this connector. You can specify a message Priority in Outlook.
It is possible to choose which allowed types of message are delivered through this connector. This makes it possible to create two connectors. One connector for only Non-system messages and one connector for System messages for a better control of message delivery.
At last you can restrict the maximum message size for this connector.
Figure 7: Configure Content Restrictions
In the Advanced Tab you can configure the SMTP Connector for the extended SMTP commands (HELO/EHLO). The Default is EHLO. Older e-mail Systems don’t understand the EHLO syntax and use HELO instead of EHLO.
Figure 8: Configure Advanced Options
Conclusion
With the help of an SMTP Connector you have complete control over the message flow in your Enterprise. The SMTP Connector is a flexible and powerful component in an Exchange Organization.
Related Links
Exchange 2003 Online help
www.microsoft.com/exchange
http://support.microsoft.com/default.aspx?scid=kb;en-us;314961
http://support.microsoft.com/default.aspx?scid=kb;en-us;265293
http://support.microsoft.com/default.aspx?scid=kb;en-us;294736
Inscription à :
Articles (Atom)