Exchange ‘Cross Forest’ Mail Migrations

Posted on 26/10/2017 by PeteLong

KB ID 0001356

Problem

PeteNetLive is full of Exchange Migration walkthroughs, going all the way back to Exchange 2003. But what if you are migrating to another forest? Well for small migrations you can of course export mail from the old Exchange Server, and them import it into the new mailbox in the new domain/forest (usually via .PST files). I’ll provide links at the bottom of the page, if that’s what you would prefer to do.

Earlier this year, I got involved with a client that was migrating many domains into one, and this method seemed a better fit for them. The process/screenshots below are taken from my testing and proof of concept for this project.

As you can see, (above) I’ve got a source Exchange server, (Running Exchange 2010) in domaina.com, and I’ve got a target Exchange server, (Running Exchange 2016) in domainz.com

Note: You may guess from the server names, these are also domain controllers, (this is not recommended in a production environment!) My old Exchange server is also running Certificate Services, which will become apparent below.

Solution

The service that does all the ‘heavy lifting’, is the Microsoft Exchange Mailbox Replication Service. Out first task is to get it running on the legacy Exchange server. Open the Exchange Shell and execute the following command;

[box]Set-WebServicesVirtualDirectory -Identity “EWS (Default Web Site)” -MRSProxyEnabled $true -MRSProxyConnections 50[/box]

Ensure the service is running;

The front end of the MRS service is presented via IIS, and it’s secured with HTTPS, so it will use the certificate you have presented, (i.e the same one for OWA). Therefore the new (Target Exchange Server) needs to trust that certificate. If you have a publicly signed certificate from a third party vendor, then you don’t need to import anything you can skip this step.

The World is Full of People Who are Scared of Certificates! I have no idea why? For a certificate to work, you need to TICK TWO BOXES;

BOX ONE: You need the trust the Certificate Authority who issued the certificate, (this is printed onto the certificate, and in most cases can be extracted from the web certificate as well. This is the CA Certificate of the issuer, NOT the certificate you see in OWA.
BOX TWO: The certificate will have a name on it, it will be either the common name, or a subject alternative name (within the certificate), it will look something like, owa.your-domain.com, or *.your-domain.com for example. This must be resolvable via DNS, and also be the hostname you are looking at.

Below, I’m simply importing the Root CA Certificate, from DomainA into my Exchange server on DomainZ.

Note: Start > Run > mmc.msc > File > Add/Remove Snap-in > Certificates > Local Computer.

In production, I’d setup conditional forwarding between the two domains to handle DNS, but in this case I’m being lazy and just putting the FQDN of the Exchange 2010 server in the Exchange 2016’s hosts file, (old school eh!)

To Setup Conditional Forwarding; Take a look at the first three steps in this article.

Providing you have done everything correctly, you should be able to ‘browse’ from Exchange 2016, to Exchange 2010, to the following URL, and not receive any certificate errors, it should look like this;

[box]https://servername.domain-name.com/EWS/mrsproxy.svc[/box]

Note: If you get any certificate/untrusted errors, fix them before proceeding.

Pre-Staging the Cross Forest MailBox Migration

Actually moving the mailboxes is a ‘two-step‘ procedure, first you pre-stage the move, this creates a Mail User* in the new domain.

*Note: A Mail User is an a little bit like a Contact insofar as they both have external email addresses (i.e ‘username@domaina.com’, while the mail user is in domainz.com, (until the mailbox is migrated). The difference between a Mail user and a contact is, a mail user has a logon name and a password. Once migrated the Mail User is converted into a User Mailbox in the new domain, and the User Mailbox back in old domain gets converted into a Mail User with an email address of username@domainz.com for the mail user in domaina.com. This (while being cool) allows mail flow between the domains during migration. (Assuming your DNS is all setup correctly, of course).

The following procedure is carried out on the new Exchange server, open an Exchange Shell Window and execute the following command;

[box]$Rcred = Get-Credential[/box]

Then supply an administrative account in the SOURCE, (remote) domain.

Repeat the procedure, but this time use Lcred;

[box]$Lcred = Get-Credential[/box]

Then supply an administrative account in the TARGET, (local) domain.

Exchange has a script to do the do the staging for you, it’s in the Exchange install directory, in the ‘scripts’ folder. Mine is in the C: drive, but the path to yours may be different, (depending on how you installed Exchange). But once located, you need to change to the directory that the Prepare-MoveRequest.ps1 script is in i.e.;

[box]cd “c:\Program Files\Microsoft\Exchange Server\V15\Scripts”[/box]

Note: V15 denotes Exchange 2013 and 2016.

Now execute the following command, (this is all one command if it gets wrapped);

[box].\PrepareMoveRequest.ps1 -Identity “username@domaina.com” -RemoteForestDomainController dc2a.domaina.com -RemoteForestCredential $Rcred -LocalForestDomainController dc1z.domainz.com -LocalForestCredential $Lcred -TargetMailUserOU “OU=Migrated,DC=domainz,DC=com“[/box]

Note: This assumes you have created the OU to migrate into! And, (as you can see in the example below,) I’m using the public email address of my user, not the internal one, (it doesn’t matter).

Execute Cross Forest Mailbox Migration

Now the mailboxes are ‘pre-staged’ we can select them for migration, in the new Exchange environment, Recipients > Migration >Add > Move to this forest.

Add.

Select the User(s) > Add > OK.

Next.

Enter the administrative credentials for the source domain > Next.

Enter the FQDN, of the legacy server, (use the SAME NAME that’s on the certificate) > Next.

Give the migration ‘Batch’ a name > Set the ‘target’ email domain > Select the target Exchange Database, (and Archive database if applicable) > Next.

Note: If you keep getting failed migrations, that say ‘FailedOther‘ then you can raise the bad item limit, and large item limits.

Select a user to get the mail notification > Select ‘Automatically Complete Migration Batch’ (or it will stop at 95% and you will have to complete this manually) > New.

You can now view progress in the ECP, (a big buggy and slow to update,) or by running ‘Get-MoveRequest | Get-MoveRequestStatistics‘

If there’s a problem, both the ECP (Exchange Control Panel) and EMS (Exchange Management Shell) should give you a clue. You can remove and rerun a migration on a failed user and nothing will break! Sometimes you need to raise the bad item limit or make sure the source mailbox isn’t too large before proceeding for example. (Use the search box at the top of the page, I’ve posted a lot of Mailbox Move problems).

Event ID 5719

Posted on 17/11/2015 by Migrated

KB ID 0000712

Problem

You see the following error in your event log (seen here in the system log on a domain controller).

Log Name: System
Source: NETLOGON
Date: 15/11/2012 06:00:35
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: Servername.Domain-Name.com
Description:
This computer was not able to set up a secure session with a domain controller in domain (domain-name) due to the following:
There are currently no logon servers available to service the logon request.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

Solution

Note: In this case the domain it could not contact was NOT my live domain name it was a different domain name. If your error is referencing your live domain name then you have a different problem.

Cause: In my case the problem was being caused because I had a domain trust to a domain that was no longer contactable, (one of my colleagues has set it up in the past to do some testing). So I simply needed to remove the trust.

Warning: In this case that trust is no longer required – Check!

1. On a domain controller > Windows Key+R > domain.msc {enter}

2. Right click the domain name > Properties > Trusts > Select the problem domain > Remove > Yes > OK.

VMware – Replace the ESXi Certificate

Posted on 17/11/2015 by Migrated

KB ID 0000974

Problem

ESXi comes with a self signed certificate, and for most people thats fine, but some clients want to have a ‘Trusted’ certificate on theirs, and have their own PKI infrastructure for issuing them.

Below I will generate a new certificate for my ESXi server using the Active Directory Certificate Services role on Windows Server 2012. Then replace the self signed certificate with my new one.

Solution

Generating a Certificate Request From the ESXi Server

1. Before we start there are a couple of hoops to jump through, and a Windows machine (it does not mater which one), install the following tow pieces of software;

Microsoft Visual C++ 2008 Redistributable Package (x86) and Shining Light Productions installer for OpenSSL x86 version 0.98r (or later)

Accept all the defaults and it should install to C:OpenSSL-Win32 go there, and in the bin directory make a backup of the openssl.cfg file.

2. Open the original openssl.cfg file and delete everything out of it, then paste in the following text, replace the values in red with your own, and save the file.

[box]

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:PNL-ESX1, IP:10.254.254.12, DNS:PNL-ESX1.petenetlive.net

[ req_distinguished_name ]
countryName = GB
stateOrProvinceName = Teesside
localityName = Middlesbrough
0.organizationName = PeteNetLive
organizationalUnitName = Technical Services
commonName = PNL-ESX1.petenetlive.net

[/box]

3. Open a command window and execute the following three commands;

[box]

cd C:OpenSSL-Win32Bin
openssl req -new -nodes -out rui.csr -keyout rui-orig.key -config openssl.cfg
openssl rsa -in rui-orig.key -out rui.key

[/box]

You will notice rui.csr has been created in the bin directory this is the file you need to request your certificate, if you open the file with Notepad you can copy the text.

Submit the Certificate Request and Get an ESX Certificate From a Windows CA

4. Open the web console of your certificate services server (it needs to be running the Certification Authority Web Enrollment role). The URL is usually http://{servers IP or Name}/Certsrv. Select ‘Request a certificate’.

5. Advanced certificate request.

6. Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

7. Paste in the text from your csr file (with no extra spaces!). Set the Certificate Template to ‘Web Server’ (the default lifetime for the Web Server template is 2 years. If you require longer, I suggest you clone the Web Server Template, change the lifetime and republish it in Active Directory Certificate Services).

8. Base 64 encoded> Download certificate.

9. Save the file as rui.cer and put it in the bin directory.

10. ESX needs the certificate to be in x509 format, so open a command window and execute the following commands;

[box]

cd C:OpenSSL-Win32bin
openssl x509 -in rui.cer -out rui.crt

[/box]

11. Enable SSH on your ESX Host.

12. Connect to the ESX host via SSH, and make a backup of the current keys (just in case).

[box]

cd /etc/vmware/ssl
mv rui.crt backup.rui.crt

mv rui.key backup.rui.key

[/box]

13. Using WinSCP copy the rui.crt and the rui.key files from the bin directory, to the /etc/vmware/ssl directory on your ESX host. WARNING: Set the copy type to ‘Text’ or ASCII or you may get some strange results.

14. Then either restart the management agents, or from your SSH session execute the following command;

[box]/sbin/services.sh restart[/box]

15. The simplest way to check is browse to the FQDN or your ESX host (the same name you used as the common name in step 2), and take a look at the certificate.

Add a URL to Clients “Trusted Sites” with Group Policy

Posted on 17/11/2015 by Migrated

KB ID 0000146

Problem

You want to have a URL added to everyone’s “Trusted Sites” list, and to avoid visiting each machine you want to use Group Policy, Or users don’t have the rights to do this themselves and you want to add one for them, i.e. the URL of your corporate CRM System.

Solution

The Group Policy you need to edit is,

Computer Configuration > Policies (This level is on Server 2008 only) > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.

Click Enabled > Show

Click “Add” > Enter the URL in the “name of the item to be added” > Enter the number 2 in “Enter the value of the item to be added” > OK > OK > Apply > OK.

On your client reboot or run “gpupdate /force”

Windows Mail can’t connect to Exchange

Posted on 17/11/2015 by Migrated

KB ID 0000662

Problem

Seen when trying to connect the Windows 8 mail client to Exchange 2010 (that is using a self signed certificate).

Error

Unable to connect. Ensure that the information you’ve entered is correct.

Solution

This is a right pain! My Exchange 2010 server is using a self signed certificate, and even though the Windows 8 client trusts my domain CA, and it has imported the cert that Exchange is using, it still would not work.

I Know the cert is OK, Outlook Web Access and Outlook work fine without reporting any certificate errors. I even put the CA FQDN in the Windows 8 hosts file in case it needed to see that (because I read that the problem is related to the client not being able to see the CA’s certificate revocation list).

The only way I found to cure this problem, and let me successfully connect to Exchange, is to remove the self signed certificate and use a purchased certificate.

Purchase your Exchange certificate here.

Juniper SRX240 – Firewall Cluster (Active / Standby)

Posted on 17/11/2015 by Migrated

KB ID 0000990

Problem

I’ve had very little exposure to JUNOS and Juniper equipment, and later in the year I have to deploy some for a client in a failover cluster. So I had a good look round on the Internet, and found loads of good blog posts and KB articles like this one. The problem is they are all geared to setting up a cluster, they ASSUME you then know about security zones, how to add default routes, and setup NAT etc. So they don’t cover that. Yes you then can set up a cluster, but it has no IP addresses, and you cant pass any traffic though it! Hopefully this will redress the balance.

Solution

Before you start, you obviously need two physical firewalls running the same OS, and this whole procedure is carried out from command line, (I’m using the console cable).

Things that took me a while to grasp, that you need to know.

1. The SRX240 has 16 ports numbered ge-0/0/0 to ge-0/0/15, when you cluster them the ports on the secondary firewall (node1) are renumbered to ge-5/0/0 to ge-5/0/16.

2. As soon as you cluster the firewalls the first port (on both) is reserved for management. That’s ge-0/0/0 and ge-5/0/0 they are then refereed to as fxp0.

3. As soon as you cluster the firewalls the second port (on both) is reserved for the firewalls control plane. That’s ge-0/0/1 and ge-5/0/1 they are then refereed to as fxp1.

4. You need to dedicate another port on both firewalls for the firewalls data link this can be any port, but to keep things simple I’ll use the next free port on both firewalls (ge-0/0/2 and ge-5/0/2). These will then be referred to as fab0 and fab1 (respectively).

Thats the clustering side of things, what about the networks I’m going to connect to the firewall. Take a look at this diagram;

Both the firewalls have a connection to each network (which makes sense if they are going to fail over). I’ve got an ‘outside’ network that connects to the Internet. ‘Inside’ I’ve got two networks, (most people reading this will have one, but remember this is practice for a live client, and they have two data LANS).

As all the networks are connected in two places, where do you assign IP addresses? Well above you can see the outside connections are plugged into ge-0/0/4 and ge-5/0/4. You add both these physical interfaces to a Reth (Redundant Ethernet Interface), and you assign the IP to that. So I have three Reth interfaces, (Reth0 for outside, Reth1 for the first inside network, Reth2 for the second inside interface).

So only Reth interfaces have IP addresses? Well no, the two fxp0 interfaces on each physical firewall, also get an IP address (for out of band management), and it’s a different one for each firewall.

Step 1: SRX240 Setup a Chassis Cluster.

1. Before we start you need to delete the existing interfaces from the config (ALL of them), otherwise you will get some errors later on when you try and commit (save) the firewall config. Also remove the hostname, we will set that in a minute.

[box] delete interfaces ge-0/0/0
delete interfaces ge-0/0/1
—Repeat for the rest of the interfaces—
delete interfaces ge-0/0/14
delete interfaces ge-0/0/15

delete system host-name[/box]

2. Connect ge-0/0/0 to management network > Connect ge-5/0/0 to management network >
Connect ge-0/0/1 on Primary to ge-5/0/1 on Standby, (this can’t be changed and will be the fxp0 connection) > Connect ge-0/0/2 on Primary to ge-5/0/2 on Standby (this can be changed but will be the fab0 and fab1 connection).

3. Carry out the following procedure on BOTH firewalls. This sets the host names of the firewalls and the IP addresses of the management interfaces.

[box]set groups node0 system host-name FW-A
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.254.1/24
set groups node1 system host-name FW-B
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.254.2/24
set apply-groups “${node}”[/box]

4. On FW-A (the primary node0) turn on clustering.

[box]set chassis cluster cluster-id 1 node 0 reboot[/box]

5. On FW-B (the secondary node1) turn on clustering.

[box]set chassis cluster cluster-id 1 node 1 reboot[/box]

6. Back on FW-A (the remainder of the config will be done on node0), set the configuration for the data link, notice I’m deleting the interface again, (I had a lot of bother with this so let’s play it safe). Then I’m saving the changes with a ‘commit’ command, because at this point if something is wrong it will tell you.

[box]delete interfaces ge-0/0/2
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
commit[/box]

Step 2 Create Redundancy Groups

1. Redundancy group 0 is created by default so set the priority for that one first.

[box]root@FW-A# set chassis cluster redundancy-group 0 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 0 node 1 priority 1[/box]

2. Create a new redundancy group that the Reth interfaces will use.

[box]root@FW-A# set chassis cluster redundancy-group 1 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 1 node 1 priority 1[/box]

Step 3 Define and Add Physical Interfaces to the Reth Interfaces

1. Define the number of Reth interfaces (two inside and one outside).

[box]root@FW-A# set chassis cluster reth-count 3[/box]

2. Allocate Reth0 to the physical interfaces (for outside).

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/4 gigether-options redundant-parent reth0
root@FW-A# set ge-5/0/4 gigether-options redundant-parent reth0 [/box]

3. Apply Redundancy group 1 to Reth0 and give it an IP Address.

[box]root@FW-A# set reth0 redundant-ether-options redundancy-group 1
root@FW-A# set reth0 unit 0 family inet address 123.123.123.123/24[/box]

4. Let’s see if that worked.

[box]root@FW-A# show chassis cluster
reth-count 3;
redundancy-group 0 {
node 0 priority 100;
node 1 priority 1;
}
redundancy-group 1 {
node 0 priority 100;
node 1 priority 1;
}[/box]

5. Setup Reth1 (inside). Add the physical interfaces, and apply redundancy group 1 (again).

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/8 gigether-options redundant-parent reth1
root@FW-A# set ge-5/0/8 gigether-options redundant-parent reth1
root@FW-A# set reth1 redundant-ether-options redundancy-group 1
root@FW-A# set reth1 unit 0 family inet address 192.168.20.1/24 [/box]

6. Setup Reth2 (inside). Add the physical interfaces, and apply redundancy group 1 (again) then save the changes.

[box] {primary:node0}[edit]
root@FW-A# edit interfaces

{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/12 gigether-options redundant-parent reth2
root@FW-A# set ge-5/0/12 gigether-options redundant-parent reth2
root@FW-A# set reth2 redundant-ether-options redundancy-group 1
root@FW-A# set reth2 unit 0 family inet address 192.168.50./24
{primary:node0}[edit interfaces]
root@FW-A# exit

{primary:node0}[edit]
root@FW-A# commit
node0:
commit complete

{primary:node0}[edit]
root@FW-A# [/box]

7. Then add the six physical interfaces that make up all the Reth interfaces to the redundancy group 1, and give each interface a ‘weighting’ of 255.

[box] {primary:node0}[edit]
root@FW-A#

set chassis cluster redundancy-group 1 interface-monitor ge-0/0/4 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/8 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-0/0/12 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/4 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/8 weight 255

{primary:node0}[edit]
root@FW-A# set chassis cluster redundancy-group 1 interface-monitor ge-5/0/12 weight 255 [/box]

Step 4 Add a ‘Default Route’ to the Internet.

1. To get traffic out to the Internet. the cluster needs the IP of its ‘next-hop’, (usually the router supplied by your ISP).

Note: If you’re anything like me after you enter this you will try and ‘ping’ the router from the firewall, or ping an Internet. IP address, at this point that wont work, (you need to allocate interfaces to security zones first).

[box]root@FW-A# set routing-options static route 0.0.0.0/0 next-hop 123.123.123.1[/box]

Step 5 Add interfaces to Security Zones and Allow Traffic Out

Note: I’m simply allowing all traffic out.

1. Make sure the Security Zones ‘Trust’ and ‘Untrusted’ Exist

[box]root@FW-A# show security zones
or
root@FW-A# run show security zones[/box]

2. Add the Reth0 Interface to the Untrusted zone.

[box]root@FW-A# set security zones security-zone untrust interfaces reth0.0 [/box]

3. Allow traffic.

[box]{primary:node0}[edit]
root@FW-A# set security zones security-zone untrust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone untrust host-inbound-traffic protocols all[/box]

4. You can check the changes before you commit them.

[box] {primary:node0}[edit]
root@FW-A# show | compare
[edit security zones security-zone untrust]
+ host-inbound-traffic {
+ system-services {
+ all;
+ }
+ protocols {
+ all;
+ }
+ }
+ interfaces {
+ reth0.0;
+ }

Save the changes

{primary:node0}[edit]
root@FW-A# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

[/box]

5. Then add Reth1 and Reth2 to the Trusted zone and repeat the process to allow all traffic.

[box]root@FW-A# set security zones security-zone trust interfaces reth1.0
root@FW-A# set security zones security-zone trust interfaces reth2.0
root@FW-A# set security zones security-zone trust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone trust host-inbound-traffic protocols all[/box]

6. Let’s check to see all that worked.

[box]

{primary:node0}[edit]
root@FW-A# show security policies from-zone trust to-zone untrust
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}

{primary:node0}[edit]
root@FW-A# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}

[/box]

Step 6 Allow Remote Management

1. We have two interfaces dedicated to out of band management, and we gave them an IP address earlier. Here I’m allowing remote administration via web to the J-Web console.

[box]root@FW-A# set system services web-management https interface fxp0.0[/box]

Step 7 Perform NAT on ‘Outgoing’ traffic.

1. Here we are doing what Juniper call ‘Source NAT‘ where we translate many addresses to one, (as in this case, but it can be a ‘pool’ of IP addresses). For the Cisco heads (like me) we are doing PAT.

Note: If you see Juniper mention ‘Destination NAT‘ they are usually talking about NATTING inbound traffic to one (or more) internal IP addresses.

[box] set security nat source rule-set TRUST-TO-UNTRUST from zone untrust
set security nat source rule-set TRUST-TO-UNTRUST to zone trust

set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match source-address 192.168.0.0/16
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match destination-address 0.0.0.0/0
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE then source-nat interface [/box]

PeteNetLive

Technology that 'Just Works'

Tag Archives: trusted

Exchange ‘Cross Forest’ Mail Migrations

Problem

Solution

Pre-Staging the Cross Forest MailBox Migration

Execute Cross Forest Mailbox Migration

Related Articles, References, Credits, or External Links

Event ID 5719

Problem

Solution

Related Articles, References, Credits, or External Links

VMware – Replace the ESXi Certificate

Problem

Solution

Generating a Certificate Request From the ESXi Server

Submit the Certificate Request and Get an ESX Certificate From a Windows CA

Related Articles, References, Credits, or External Links

Add a URL to Clients “Trusted Sites” with Group Policy

Problem

Solution

Related Articles, References, Credits, or External Links

Windows Mail can’t connect to Exchange

Problem

Solution

Related Articles, References, Credits, or External Links

Juniper SRX240 – Firewall Cluster (Active / Standby)

Problem

Solution

Step 1: SRX240 Setup a Chassis Cluster.

Step 2 Create Redundancy Groups

Step 3 Define and Add Physical Interfaces to the Reth Interfaces

Step 4 Add a ‘Default Route’ to the Internet.

Step 5 Add interfaces to Security Zones and Allow Traffic Out

Step 6 Allow Remote Management

Step 7 Perform NAT on ‘Outgoing’ traffic.

Related Articles, References, Credits, or External Links