@scottalanmiller said:

@Dashrender said:

@StefUk said:

@Dashrender

@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

Why 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.

that would be fine if no one was going to work for the next two months or no changes where going to be made the main data migration still need to be done over a week end and out of hrs.

@scottalanmiller said:

@Jason said:

Seems like this is the first thing that should be addressed.

That would be my approach, if this were my project I would push on them HARD to determine that this is absolutely the truth and not just something that they are saying to blow off the idea. It's possible, but should lead to some questions about how they got into this state and how to avoid it in the future. I get the tight time frame, but this is making it tighter and getting the full picture here would potentially solve a lot of other things. Not everything by any stretch, but a bit.

the legacy application is not compatible doesn't work with o365. the software vendor of the Document management sends emails with a tag so they can track all correspondence and auto save on to the documents management under each client without manually saving each email. this is done at the exchange level.

@Dashrender

@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

@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

@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
s

There 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

@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:

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 ..

@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

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

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

@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:

1. 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.

2. 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:

2. 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.

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

@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 package

and 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

@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 package

and some other generic apps like antivirus - internet filtering etc

I think we are going off track ...

we are discussing why they use VPN when the VPN was never been mentioned as an issue here. Both solution works fine, we are not looking at saving money or justify expenditure I was just reaching out to understand how we can incorporate the apps of the two companies in to one without causing too much downtime.

Company A and company B are merging on to company C with company B moving to company A . How can I get the two systems to work from company A premise in a short time as possible ?

How can you merge comany A AD on to company B AD ?

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 .

is that more to the point ?

@hobbit666 said:

@StefUk said:

@scottalanmiller said:

We could ask in another way, given that they chose a VPN to connect the offices, why is there RDP? What is the VPN not handling well that as made them feel the need to have redundant connection technologies back to the main office?

line speed at each office is slow ( less then 10Mbps ) . Rdp ( remote desktop ) solutions is used to compress the data and make the application work at the branch offices. without the rdp the apps run too slow at think client.
is that what you are asking ? everything is hosted at the main office

Think what they are both trying to say is you don't need the VPN link to use RDP to the HO location. Open up the ports on the Firewall and allow access through the internet connection.

The VPN link is not required for what you are using i.e. RDP

ok maybe we don t need it but I don t have time to create more work for me .. it works and I don t need to change it . it doesn't cost anything and I don t have a problem with this .. ?
i would like to know what i can do with the AD - exchange - LAN etc ..maybe i should post something more specific

@scottalanmiller said:

We could ask in another way, given that they chose a VPN to connect the offices, why is there RDP? What is the VPN not handling well that as made them feel the need to have redundant connection technologies back to the main office?

line speed at each office is slow ( less then 10Mbps ) . Rdp ( remote desktop ) solutions is used to compress the data and make the application work at the branch offices. without the rdp the apps run too slow at think client.
is that what you are asking ? everything is hosted at the main office

@scottalanmiller said:

@StefUk said:

i don t understand .. what you mean.
VPN's are there to connect offices to the main office where the main apps are hosted via rdp. again it is what it is .. at list they use the same way of connecting offices RDP

I understand that "it is what it is", but... why? I'm confused... is the goal here to "maintain the technical debt" in which case there is literally nothing to be done, just leave it all as it is. Or is the goal to "do the best thing going forward?" If the latter, then we must understand the reasoning and logic for the existing system to understand what makes sense to meet their needs in the future.

If we ever say "let's not go into this" then the entire point of trying to recommend anything for them is pointless, the decisions are made and this is a farce. We have to examine their past and their needs in order to find out what is a good solution for them.

So the question remains: what is the function of the VPN? Why does it exist? Does it have a purpose or is it just technical debt kept around because no one is evaluating needs until now?

the site to site VPN is there as a way to connect the branch office to the main office .. how do you suggest they connect to the main office to access the core applications ? cloud - hosted application is not an option .

@scottalanmiller
i don t understand .. what you mean.
VPN's are there to connect offices to the main office where the main apps are hosted via rdp. again it is what it is .. at list they use the same way of connecting offices RDP

s

@scottalanmiller

yes the legal industry is what it is ... no option to change the DMS systems