Merger
-
@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?
-
@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.
