Merger
-
@scottalanmiller said:
@StefUk said:
@Dashrender said:
@StefUk said:
are not looking at saving money or justify expenditure I was just reaching out to understand how we can incorporate the apps
Are you merging the datacenters?
What are the applications, specifically? Sometimes different apps have different requirements, so a blanket response will be of little help.
both companies have a fully working infrastructure in house. In two months time company B will move in to company A. company B computers will be plugged in to company A data center ( infrastructure). at that stage, if the new merged company infrastructure ( company C ) is not ready how can i mitigate the move.
The core application are
specific legal - accounting package and document management. ( different for company a and b at the moment - the plan is to move company b to company A app)
Email - exchange ( one server for each company )
file and print server
AD
Remote desktop
SQL dictation package
a legal form packageand some other generic apps like antivirus - internet filtering etc
I guess the biggest question is... what is the end goal? One single AD, one email, one application or is the goal to keep operating as two companies? I get that you might not want to jump all of the way to a fully merged company on day one, but it sounds like almost as much effort to hold off on the merging of everything but the applications themselves than to just merge it from the beginning.
Why not just make a new AD system and a new Exchange system and move everyone equally to a single, new, pristine environment designed from the ground up for the operations of the new company?
i think that is the most sensible way forward instead of trying to figure out a way of integrating the two ..without VPN of course
-
@StefUk said:
i think that is the most sensible way forward instead of trying to figure out a way of integrating the two ..without VPN of course
How does the VPN help, though? I think a VPN does something different than assumed. If you are using RDP they are already integrated. The VPN is just a red herring, extra work. It's not providing anything, right?
-
For example, NTG is integrated with its remote users, but there is no VPN. In our case it is not because we are using RDP, but it is the same difference. If we implemented a VPN, people might feel like the VPN was handling some part of the integration, but it is not, our applications are doing that. If we turned on a VPN the VPN itself would be idle, doing nothing. It might look to someone doing a quick audit that it was serving a purpose, but you would be able to turn it off and everything would work the same as before.
-
@scottalanmiller Still waiting for your report/article on NTG's rise to a LANless design
-
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.
-
-
@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.
- networks use different IP schemes (i.e. A - 172.16.1.x/24 and 10.0.0.x/24)
-
As for the VPN's, as Scott mentioned, assuming you are only using them for RDP access, get rid of them. Instead create the firewall rules that allow RDP access to the RDS servers directly. If you don't have multiple IP addresses at the firewall, there will be more work to do.
But if VPNs are used for more than RDP, have all locations converge on company A's firewall and get rid of company B's firewall (the main office one, obviously the remote offices will need to keep theirs).
-
@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 gave options, not recommendations - though if you're looking at my list of options as a list of recommended ways of doing this, the option 1 is above option 2, which is more or less what you were saying.
- networks use different IP schemes (i.e. A - 172.16.1.x/24 and 10.0.0.x/24)
-
@Dashrender said:
As for the VPN's, as Scott mentioned, assuming you are only using them for RDP access, get rid of them. Instead create the firewall rules that allow RDP access to the RDS servers directly. If you don't have multiple IP addresses at the firewall, there will be more work to do.
And put in an RDS Web Gateway. Works great and covers any security concerns by creating SSL connections for the RDP.
-
@Dashrender said:
But if VPNs are used for more than RDP, have all locations converge on company A's firewall and get rid of company B's firewall (the main office one, obviously the remote offices will need to keep theirs).
Yes, one way or another the VPN infrastructure sounds like it has to be addressed, and I mean has to be or things won't function. So no matter how much we feel like sticking our heads in the sand or acting like this isn't a core decision point, it really is. It's unavoidable. If AD, Exchange, RDP or anything else is to be discussed, the VPN is part of all of those and cannot be treated as a foregone conclusion because the existing VPN system won't work with the intended future design(s).
-
Putting the Exchange servers, AD servers, etc, etc, etc all on the same network won't affect the way any of it works.
For example, the Exchange servers will still talk to each other as if they are in different companies, but now they will talk at local speeds.
FYI, if you don't have multiple IPs for the firewall at company A, you'll need to make sure DNS either enables it to find the local IP, or that the firewall supports hairpin routing.
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.
-
@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.
-
@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.
-
@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.
I think he means proxy between the two servers.. Setup one then the other can forward the emails to the second one.
-
@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.
Internally - this is easy. Both ADs would have their DNS updated to include the DNS information from the other domain. All intra-company (A to B and B to A) would have no reason to leave the firewall. And all of this is assuming there are no other gateways that are involved to keeping copies of all emails.
-
@Dashrender said:
eh? How does that solve an external entity sending them email.
Oh sorry, I see what you mean.
-
@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.
-
