Merger
-
@Jason said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Though having two email servers behind the same IP going to two different serves both on port 25 will have other challenges you'll have to over come.
MX record on local DNS... easy peasy.
eh? How does that solve an external entity sending them email.
Assumption - Company A has one IP, external vendor sends email address.. .both global DNS servers say go to same IP address - the firewall receives the packet - then what? How does the firewall know which server to send it to?
Is there an NGIX for email? I know there are mail routers (or whatever they are called) but I don't know (haven't had the personal need) for a device to intercept an email, read the destination and then send A left and B right.
Setup one then the other can forward the emails to the second one.
Aww - I've done that I guess. good call.
-
@Dashrender said:
Is there an NGIX for email?
I don't think that that is what you mean. Nginx is a web server. So the most direct equivalent would be "an email server." Postfix being the most similar (easy, popular, free, open). In the Windows world, the "Nginx of email" would just be... Exchange.
-
@scottalanmiller said:
@StefUk said:
Company A has an exchange company B has an exchange, when compnay B moves in to company A is there a way to make exchange from company B to talk to exchange in to company A and vice versa without migrating mailboxes to a new exchange .
I don't understand this bit - or more I don't understand the "why" of this bit. what is the goal in merging the email systems (before fully merging them?) Email systems talk to each other natively, that's what email does. What do you specifically want these email systems to do with each other?
if we don't merge the two email systems, when company B relocates to company A how can users from company B still access the mailbox from company A infrastructure ? i am try to work out the logistics of making this work ..
-
@Dashrender said:
The biggest issue I see on day one of moving the hardware from company B's location to company A's location will the an IP schema issue.
There are two possibilities here:
-
both networks use the same IP scheme (i.e. 172.16.1.x/24) and have devices that are assigned the same IP. For example, they both have servers on IP 172.16.1.1.
I'd solve this by changing the servers/printers/switches, etc to IPs not in use on company A. then you can just plug them into the network there and continue to work as if nothing has changed. -
networks use different IP schemes (i.e. A - 172.16.1.x/24 and 10.0.0.x/24)
This situation is a bit easier assuming the default Gateway in company A can be multi-homed (have two or more internal networks). You have a few choices. Create a VLAN for company B's IP range, create an interface on the firewall for this new network, assign all ports for the company B computers/servers, etc to the new VLAN. Another option would be to bring company B's switches over, use them for company B computers and connect them also to the new port created on the firewall.
@Jason said:
@Dashrender said:
- networks use different IP schemes (i.e. A - 172.16.1.x/24 and 10.0.0.x/24)
This situation is a bit easier assuming the default Gateway in company A can be multi-homed (have two or more internal networks).
That's adding complexity (and Latency) for no reason.. Just rescope. You almost always have to rescope with mergers anyway.
i think you have both hit a good point. The two scopes are different and I would want company B scope to change and bring it in line with company A. Re scoping and setting up a trusted domain binding should allow for the two infrastructure to coexist locally.
-
-
@StefUk said:
if we don't merge the two email systems, when company B relocates to company A how can users from company B still access the mailbox from company A infrastructure ? i am try to work out the logistics of making this work ..
Not sure that I see the issue. I might just be missing something. Obviously long term you want to merge the email systems, until then, they should "just work", right? Ideally, merge them right away and have that out of the way, I would think. Fewer moving parts to have being problematic later.
-
@StefUk said:
i think you have both hit a good point. The two scopes are different and I would want company B scope to change and bring it in line with company A. Re scoping and setting up a trusted domain binding should allow for the two infrastructure to coexist locally.
You don't need to rescope to do that. You can have two unique subnets on the same LAN. Horrible idea, just pointing out that rescoping is not what enables this.
-
@scottalanmiller said:
@StefUk said:
if we don't merge the two email systems, when company B relocates to company A how can users from company B still access the mailbox from company A infrastructure ? i am try to work out the logistics of making this work ..
Not sure that I see the issue. I might just be missing something. Obviously long term you want to merge the email systems, until then, they should "just work", right? Ideally, merge them right away and have that out of the way, I would think. Fewer moving parts to have being problematic later.
I get they should be merged .. but how can exchange - mailboxes etc work when company B moves to company A ?
-
@StefUk said:
I get they should be merged .. but how can exchange - mailboxes etc work when company B moves to company A ?
I'm unsure which aspect is worrying you. Do you mean in email routing to different @ addresses?
-
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
-
@Minion-Queen said:
This would be a case to move them to Office 365 for their email portion at least. You can easily migrate them all over to O365 exchange and have multiple domains for people to be receiving at.
They say that they have a dependency that O365 cannot address.
-
Is that for the MSOffice portion or email?
-
-
@StefUk said:
i think you have both hit a good point. The two scopes are different and I would want company B scope to change and bring it in line with company A. Re scoping and setting up a trusted domain binding should allow for the two infrastructure to coexist locally.
You can do this work now. At company B, change the IP scheme to match the scheme at company A. Of course you'll need to audit company A first to make sure you don't create any overlap.
-
@scottalanmiller said:
@StefUk said:
I get they should be merged .. but how can exchange - mailboxes etc work when company B moves to company A ?
I'm unsure which aspect is worrying you. Do you mean in email routing to different @ addresses?
the @ address is not the issue.
Once the clients pc of company B move to company A where they going to authenticate, resolve the dns for the exchange - mailbox etc ?
-
Trusted domain shoudl work fine... but is there a good reason not to merge AD right away? Just wondering, while a pain up front, this is not such a big place that it can't be done in a weekend and then things would be "just ready" for the future.
-
@StefUk said:
@scottalanmiller said:
@StefUk said:
I get they should be merged .. but how can exchange - mailboxes etc work when company B moves to company A ?
I'm unsure which aspect is worrying you. Do you mean in email routing to different @ addresses?
the @ address is not the issue.
Once the clients pc of company B move to company A where they going to authenticate, resolve the dns for the exchange - mailbox etc ?
You have to move ALL of the servers of company B to company A's datacenter... and put them on the network.
-
@StefUk said:
Once the clients pc of company B move to company A where they going to authenticate, resolve the dns for the exchange - mailbox etc ?
Wherever you tell them to
Decide how AD is going to be handled first, then deal with Exchange. But if you have a trust domain, just make the info the same. If you merge AD, then everything is done already. -
Company B PCs will still authenticate to Company B's domain controllers, at least until you move to over to company A's domain.
But moving them to A seems pointless since you said you want to create a new company called C. So just leave them on the domain they are on until you make company C domain and then move everyone.
-
@scottalanmiller said:
@StefUk said:
Once the clients pc of company B move to company A where they going to authenticate, resolve the dns for the exchange - mailbox etc ?
Wherever you tell them to
Decide how AD is going to be handled first, then deal with Exchange. But if you have a trust domain, just make the info the same. If you merge AD, then everything is done already.if we merge AD we wont be having this conversation haha ...
the AD merger it's something we need to think ... the complication there is that they want to become company C so need to reconnect all the client to that domain once done
s -
@StefUk said:
if we merge AD we wont be having this conversation haha ...
See, doesn't that make it simple?
