Showing posts with label configure. Show all posts
Showing posts with label configure. Show all posts
Sunday, August 28, 2016
dcpromo demote Win2k3 server Failed to configure the service NETLOGON as requested
dcpromo demote Win2k3 server Failed to configure the service NETLOGON as requested
Heres the full text of the error received:
the operation failed because:
Failed to configure the service NETLOGON as requested.
"The wait operation timed out"
and in the dcpromo.log is the following:
07/07 09:02:24 [INFO] Informed NETLOGON to deregister records
07/07 09:02:24 [INFO] Stopping service NETLOGON
07/07 09:04:24 [INFO] StopService on NETLOGON failed with 258
To fix:
Change the first DNS setting on your network card to point to your new DNS server, not the server you are currently demoting. Once you change the DNS setting to the new DNS server you will be able to demote the server without this issue.
Thursday, August 25, 2016
Configure Two Ironport C Series Devices Where the Backup Hosts the Quarantine
Configure Two Ironport C Series Devices Where the Backup Hosts the Quarantine
These steps come straight from Cisco and it works like a charm. This allows the primary device to focus on email filtering and the second device to take care of the quarantine work. I have another post on how to sync the SLBL on these two devices since users will be getting their information from the backup IronPort.
How to configure two C-Series devices where the backup hosts the Quarantine
Question: How to configure two C-Series devices where the backup hosts the Quarantine Answer All-in-one-plus-one IronPort Spam Quarantine Configuration
Note: This approach will not work if using Centralized Management.
Many sites will run two IronPort appliances, one that is designated as the "Primary MX" server and processes the majority of mail, and a second appliance as a hot spare that is designated as the "Secondary MX." If the Primary MX should become unavailable for any reason, then the normal SMTP protocol will redirect traffic to the Secondary MX until the primary is available again. For sites that wish to deploy the IronPort Spam Quarantine feature for their end-users but do not have enough traffic to justify a dedicated M-Series appliance, we offer the below configuration hints to allow you to configure the Secondary MX system to act as a centralized quarantine for both appliances, and to tell the Primary MX that messages detected as spam should be sent to that central quarantine on the Secondary MX system.
Please note that this configuration should only be used by sites that are not at or near the peak performance throughput on their Primary MX server, or doing equal-weighted load balancing between two appliances, as the additional load of processing end-user quarantined messages could result in reduced throughput in the event of a Primary-to-Secondary fail-over. For high-volume sites whose multiple appliances are running at or near peak throughput, we recommend deployment of the M-Series appliance to offload quarantine duties from your C-Series appliances.
The second IronPort MGA that will contain the IronPort Spam Quarantine, must be able to identify messages coming from the Primary MTA and force the messages to the Quarantine. This can be accomplished by using an X-Header once a messages is identified as spam.
To avoid having two IronPort C-Series MGAs scanning the same message be sure to perform the following steps.
Procedure overview:
1. On the Primary
1. Ensure messages received from Primary MX MGA are scanned for Anti-Spam filtering
2. When Spam Positive and/or Suspect Positive, send to the IronPort Spam Quarantine and add X-Header: X-Ironport-Quarantine
2. On the Secondary
1. add a Mail Flow Policy which by-passes Anti-Spam scanning
2. Add a new Sender Group called "Quarantine_From_Primary", set the order # to 1.
3. Configure this Sender Group to accept messages from the Primary appliance
4. Configure this Sender Group to use the Mail Flow Policy created previously
5. Configure the local quarantine on the "secondary" MGA
6. Edit Log Global Settings to monitor the X-header: X-Ironport-Quarantine
3. Test
If this is not setup correctly one message will actually be scanned by both MGA’s before ending up in the quarantine.
(The following example is using a Sender Group on the secondary MX MGA called "QUARANTINE_FromMail2")
Primary Server
Thu Apr 27 15:05:45 2006 Info: New SMTP ICID 1348 interface Mail (192.168.1.2) address 1.1.1.1 reverse dns host pproxy.gmail.com verified yes
Thu Apr 27 15:05:45 2006 Info: ICID 1348 ACCEPT SG SUSPECTLIST match sbrs[-2.0:-0.5] SBRS -1.4
Thu Apr 27 15:05:45 2006 Info: Start MID 1661 ICID 1348
Thu Apr 27 15:05:45 2006 Info: MID 1661 ICID 1348 From:
Thu Apr 27 15:05:45 2006 Info: MID 1661 ICID 1348 RID 0 To:
Thu Apr 27 15:05:45 2006 Info: Start MID 1661 ICID 1348
Thu Apr 27 15:05:45 2006 Info: MID 1661 ICID 1348 From:
Thu Apr 27 15:05:45 2006 Info: MID 1661 ICID 1348 RID 0 To:
Thu Apr 27 15:05:45 2006 Info: MID 1661 Message-ID <16ac64320604271305o755483cdx28677153c5e4032@mail.spammer.com>
Thu Apr 27 15:05:45 2006 Info: MID 1661 Subject Fwd: Impotenc-e hellp no doc visilt
Thu Apr 27 15:05:45 2006 Info: MID 1661 ready 13559 bytes from
Thu Apr 27 15:05:45 2006 Info: MID 1661 matched all recipients for per-recipient policy DEFAULT in the inbound table
Thu Apr 27 15:05:51 2006 Info: MID 1661 using engine: CASE spam positive
Thu Apr 27 15:05:51 2006 Info: EUQ: Tagging MID 1661 for quarantine
Thu Apr 27 15:05:51 2006 Info: MID 1661 antivirus negative
Thu Apr 27 15:05:51 2006 Info: EUQ: Tagging MID 1661 for quarantine (X-Ironport-Quarantine)
Thu Apr 27 15:05:51 2006 Info: MID 1661 queued for delivery
Thu Apr 27 15:05:51 2006 Info: Delivery start DCID 4789 MID 1661 to RID [0] to offbox IronPort Spam Quarantine
Thu Apr 27 15:05:51 2006 Info: Message done DCID 4789 MID 1661 to RID [0]
Thu Apr 27 15:05:51 2006 Info: MID 1661 RID [0] Response ok: Message 22017 accepted
Thu Apr 27 15:05:51 2006 Info: Message finished MID 1661 done
Secondary Server
Thu Apr 27 15:05:50 2006 Info: New SMTP ICID 121070 interface Mail (192.168.1.2) address 192.168.1.2 reverse dns host unknown verified no
Thu Apr 27 15:05:50 2006 Info: ICID 121070 ACCEPT SG QUARANTINE_FromMail2 match 192.168.1.2 SBRS rfc1918
Thu Apr 27 15:05:50 2006 Info: Start MID 22017 ICID 121070
Thu Apr 27 15:05:50 2006 Info: MID 22017 ICID 121070 From:
Thu Apr 27 15:05:50 2006 Info: MID 22017 ICID 121070 RID 0 To:
Thu Apr 27 15:05:55 2006 Info: ICID 121070 close
Thu Apr 27 15:05:50 2006 Info: Start MID 22017 ICID 121070
Thu Apr 27 15:05:50 2006 Info: MID 22017 ICID 121070 From:
Thu Apr 27 15:05:50 2006 Info: MID 22017 ICID 121070 RID 0 To:
Thu Apr 27 15:05:50 2006 Info: MID 22017 Message-ID <16ac64320604271305o755483cdx28677153c5e4032@mail.spammer.com>
Thu Apr 27 15:05:50 2006 Info: MID 22017 Subject [SPAM] Fwd: Impotenc-e hellp no doc visilt
Thu Apr 27 15:05:50 2006 Info: MID 22017 ready 13907 bytes from
Thu Apr 27 15:05:50 2006 Info: MID 22017 matched all recipients for per-recipient policy DEFAULT in the inbound table
Thu Apr 27 15:05:50 2006 Info: EUQ: Tagging MID 22017 for quarantine (X-Ironport-Quarantine)
Thu Apr 27 15:05:50 2006 Info: MID 22017 queued for delivery
Thu Apr 27 15:05:54 2006 Info: RPC Delivery start RCID 10882 MID 22017 to local IronPort Spam Quarantine
Thu Apr 27 15:05:54 2006 Info: EUQ: Quarantined MID 22017
Thu Apr 27 15:05:54 2006 Info: RPC Message done RCID 10882 MID 22017
Thu Apr 27 15:05:54 2006 Info: Message finished MID 22017 done
Detailed Steps for Primary Server
1. Ensure messages received from Primary MX MGA are scanned for Anti-Spam filtering
1. Ensure that Anti-Spam scanning is enabled
2. Configure the appropriate Anti-Spam policies on the Incoming Mail Policies page to send Positive and/or Suspect spam to the IronPort Spam Quarantine (now hosted on the Secondary MX appliance)
1. (Mail Policies -> Email Security Manager -> Incoming Mail Policies)
2. Configure the default Mail Policies: Anti-Spam settings ; Positively-Identified Spam Settings actions also to include additional X-header:
1. Header Name: X-Ironport-Quarantine
2. header Text: offbox (any text value will work)
3. If desired, repeat the above for Suspected Spam Settings
4. Setup an External Quarantine
1. Designate the Secondary MX appliance as an External Quarantine host by navigating to Monitor -> Quarantines -> External Quarantines
2. Click the "Add Quarantine..." button
3. Enter a descriptive name so you know you are routing to your Secondary MX appliance
4. Enter the IP address of the Secondary MX appliance
5. Change the default port from 6025 to 25
6. Submit
7. Commit changes
Detailed Steps for Secondary Server
1. On IronPort that will host the Quarantine (Secondary) add a Mail Flow Policy
1. Select the Mail Flow Policies, beneath the HAT Overview
2. Click the Add Policy, button
3. Name the policy, example: SpamQuarantine
4. Connection Behavior set to Accept
5. In the Security Features, turn off Virus Protection and Spam Protection
6. Turn Off Sender Verification
7. Select Submit
2. Add a new Sender Group called "Quarantine_From_Primary", set the order # to 1.
1. Open the HAT Overview, add a new Sender Group
2. Click Add Sender Group
3. Name: Quarantine_From_Primary
4. Set Order to 1
5. Add comments
6. Select the new Policy created, example SpamQuarantine
7. Leave other fields, unchecked
8. Click the Submit and Add Senders, at the bottom right.
9. Enter the IP of the Primary IronPort.
10. Add comments
11. Check Submit
12. Configure Local Quarantine
13. Enable Local quarantines
14. Monitor-> Quarantines-> Local Quarantines
3. Edit Log Settings
1. System Administration > Log Subscriptions -> "Global Settings" box,
2. click "Edit Settings..."
3. In the "Headers (Optional)" text box add: X-Ironport-Quarantine
4. Test
1. Send messages that have spam (use X-header: X-Advertisement: spam)
2. Send messages that do not contain spam
3. Review the logs
Saturday, August 20, 2016
Configure an External Time Source in Windows Server 2008 R2
Configure an External Time Source in Windows Server 2008 R2
Configure an external time source
This computer is configured to hold the primary domain controller (PDC) emulator operations master role (also known as flexible single master operations or FSMO) in the forest root domain. This computer should not use itself as a time source. Configure an external time source as the authoritative time source for the forest, or configure a member domain controller as the time source peer. The configuration must be done manually. Perform the following procedure on the computer that is logging the event to be resolved.To perform this procedure, you must have membership in Domain Admins, or you must have been delegated the appropriate authority.
To configure a manual time source peer:
- Open a command prompt as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
- At the command prompt, type w32tm /config /manualpeerlist:server,0x8, /syncfromflags:manual /update, where server is the name of the time source that you want to configure, and then press ENTER. ((I recommend pool.ntp.org for an Internet source))
- Restart the Windows Time service. At the command prompt, type net stop w32time & net start w32time, and then press ENTER.
- Resynchronize the Windows Time service client with the time source peer. At the command prompt, type w32tm /resync, and then press ENTER.
To learn more about the Windows Time service and related tools, see Windows Time Service Tools and Settings (http://go.microsoft.com/fwlink/?LinkID=42984).
To verify that the Windows Time service is synchronizing correctly:
Verify
To perform this procedure, you must have membership in Administrators, or you must have been delegated the appropriate authority.To verify that the Windows Time service is synchronizing correctly:
- Open a command prompt as an administrator. To open a command prompt as an administrator, click Start. In Start Search, type Command Prompt. At the top of the Start menu, right-click Command Prompt, and then click Run as administrator. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
- At the command prompt, type W32TM /resync, and then press ENTER.
- At the command prompt, type W32TM /query /status, and then press ENTER. This command displays the status of the Windows Time service synchronization. The Last Successful Sync Time line of the output displays the date and time that you ran the W32TM /resync command in the previous step. Also, check the computer name that is shown as the Source. This should be the name of a domain controller (or an administrator-configured time server) in the same Active Directory domain as the local computer.
Subscribe to:
Posts (Atom)