Merger
-
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?
-
@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.
-
@StefUk said:
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
When I say "merge them now", I mean... into company C. Do it all, right now. Just just right to the end game and be done with it. I'm not saying that that is the answer, but I want to know why it isn't
-
@Dashrender said:
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.
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 .. -
@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?
