Merger
-
@StefUk said:
so i ll bring the servers from company B and plug them in to company A . As they have a separate subnet they will still work and see the old domain etc ?
this is contingency plan in case we don t get everything done ..Yup, just about everything (except DHCP of course) will "just work" because it is on the IP layer. Things that won't work are things that are layer 2, like DHCP. No business function should be at that level, so not an issue.
-
@scottalanmiller said:
@StefUk said:
so i ll bring the servers from company B and plug them in to company A . As they have a separate subnet they will still work and see the old domain etc ?
this is contingency plan in case we don t get everything done ..Yup, just about everything (except DHCP of course) will "just work" because it is on the IP layer. Things that won't work are things that are layer 2, like DHCP. No business function should be at that level, so not an issue.
Right DHCP will be the problem here. To solve this, you should change Company B to use the same IP range as company A NOW. As I've posted at least 3 times already. You'll need to make sure you audit the IPs in use at Company A and don't use those IPs when changing IPs at company B.
Then when you bring it all over, you will just plug and go!.One other thing, you should make the firewall's be the same IP address at company B as Company A uses. This will be one less thing you would have to worry about when you move the equipment.
-
@scottalanmiller said:
@StefUk said:
if we merge AD we wont be having this conversation haha ...
See, doesn't that make it simple?
really simple .. the AD merger is not the issue. The issue is the time-scale with the legacy apps. If the "accounts" software is not merged and the two company cant use the merged one we will still need to use two separate systems until this happens. But company B needs to get out of the building in two month, legacy software working or not. This is why i am planning a contingency as no everything is dictated by us ( IT) . i asume we can migrate just that app
-
@Dashrender said:
@StefUk said:
@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
sThere are tools to do that.
Build a brand new AD from scratch, then use the MS tools to import your users over. There used to be tools for importing computers as well.
we will need to rejoin all the servers and clients to the new domain ? s
-
This is a pretty huge project, lots of moving parts.
There is a ton of documentation you need to make before you considering moving anything. Then review it with management to make sure nothing is missed.
The setup a strategy for moving each piece. Understand that even though each piece will have it's own strategy for moving, some parts might be the same plan.
-
@Dashrender said:
@scottalanmiller said:
@StefUk said:
so i ll bring the servers from company B and plug them in to company A . As they have a separate subnet they will still work and see the old domain etc ?
this is contingency plan in case we don t get everything done ..Yup, just about everything (except DHCP of course) will "just work" because it is on the IP layer. Things that won't work are things that are layer 2, like DHCP. No business function should be at that level, so not an issue.
Right DHCP will be the problem here. To solve this, you should change Company B to use the same IP range as company A NOW. As I've posted at least 3 times already. You'll need to make sure you audit the IPs in use at Company A and don't use those IPs when changing IPs at company B.
Then when you bring it all over, you will just plug and go!.One other thing, you should make the firewall's be the same IP address at company B as Company A uses. This will be one less thing you would have to worry about when you move the equipment.
brilliant ... thanks .. it makes sense ..
we getting somewhere ..
s -
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
-
@StefUk said:
@scottalanmiller said:
@StefUk said:
if we merge AD we wont be having this conversation haha ...
See, doesn't that make it simple?
really simple .. the AD merger is not the issue. The issue is the time-scale with the legacy apps. If the "accounts" software is not merged and the two company cant use the merged one we will still need to use two separate systems until this happens. But company B needs to get out of the building in two month, legacy software working or not. This is why i am planning a contingency as no everything is dictated by us ( IT) . i asume we can migrate just that app
Well those are the questions that we would have... what are the apps and what causes them to not be able to be migrated with the AD merger?
But okay, building evacuation is a concern... you can just do a lift and shift of the gear as is right now (like literally, this weekend, for example) with almost no planning and just move them to the other building. As they have a full infrastructure you can run them side by side for now.
No need to even merge the networks, keep them separate for the moment.
-
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
s -
As Scott said, just pick up everything and make them separate at company A. You can even get your ISP to drop another line to the building so you have two connections, one for each business.
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
Of course doing that will still require the merger stuff we've talked about before.
-
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
-
@Dashrender said:
As Scott said, just pick up everything and make them separate at company A. You can even get your ISP to drop another line to the building so you have two connections, one for each business.
No need for that, just an IP address.
-
@Dashrender said:
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
No need, just use a real router
Like a $95 Ubiquiti. -
@Dashrender said:
@StefUk said:
@Dashrender said:
@StefUk said:
i asume we can migrate just that app
Why do you assume this? How does the app work? How does it authenticate? How much data does it have?, etc, etc.
i keep missing the quotes .. if AD is merged, exchange merged, RDP and the only outstanding from company B is the APP , instead of bringing the entire infrastructure just to run the app, i can migrate the app,
sWhy are you merging twice though? or more like.. merging once and migrating once?
Merging company B into company A, then migrating company A into company C? Why not skip all that and just create C and migrate everything directly into it?
That's how I feel. Start this now, move fast. Might be done in two weeks with six weeks to sit back and relax.
-
@scottalanmiller said:
@Dashrender said:
Though you can instead, if your ISP supports it, split the one connection over the two firewalls with a switch. This would allow you to have everything remain completely separate.
No need, just use a real router
Like a $95 Ubiquiti.Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
Though, how would you solve one IP for two RDS servers on the same IP/port? You found a good solution (OK Jason did) for the email one IP (Company A's email server receives all email, then forwards company B's email to company B's Exchange server. Though not sure how that would work in totally separate networks.
-
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
-
@Dashrender said:
Though, how would you solve one IP for two RDS servers on the same IP/port?
RDS Gateway. but no need, any real router will do multiple IPs on one WAN link.
-
@scottalanmiller said:
@Dashrender said:
Sure - but then the networks wouldn't be really separate. Though perhaps that wouldn't be a problem.
What do you mean? They'd be just as separate. In what way would they be less separate?
aww.. you're assuming a second IP on the ERL.. gotcha.
-
@scottalanmiller said:
@Dashrender said:
Though, how would you solve one IP for two RDS servers on the same IP/port?
RDS Gateway. but no need, any real router will do multiple IPs on one WAN link.
yeah, you mentioned an additional IP, I was leaving that out.
-
@scottalanmiller said:
@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.
What is that?
