@ambarishrh cheap storage don't mean good .. there's no SLA's on the site for example ... sounds a bit sketchy to me ..

Oxford here ..
s

I think it's still worth going to spiceworld London.

As far as content goes, for an IT tech conference, you get a lot of interesting talsk and not always from vendors. The drill is stil the same, ie vendors flussing things up, but I find it interesting depending on the projects that you are involved in you can always make some good conversation. Most of vendors are pretty nice @Lenovo - unitrends - cyberoam - webroot etc .. you ll always get some annoying one ..

In terms of value for money .. you get decent food, decent swag and a good free booze party ... I don t think is all that bad..

I can't compare it the Austin one but as a UK venue it's not all that bad ... will need to find the time to come over the pond and sample the Austin one ..I hope soon ...

Stef

I m on too ...

hey ... looks like i m late to the game but I m sure I the first Italian on here !! ;o)
Ciao

Hi everyone,
thanks for chiming in ... and thanks @scottalanmiller for posting this on my behalf.

RDS is currently out of the question at the moment due to intense graphical resources that they need. We are looking at some long term solutions - Nvidia Grid of some sort but at the moment RDS will not cut it.

stef

Company A and company B have merged and the want to become company C in few months.
Company A 80 users – virtualised esxi and with scope to accommodate a lot more infrasrtructure has a domain – exchange in house – accounts package – 4 branch offices and other key apps
Company B 60 users virtualised hiperv ( no much scope for expansion ) has the same as company A but only 3 branch offices and they are in a separate location.
Now a decision has been made that company B will move in to the same premise of company A and company B will adopt some application that company A uses for key function like accounts etc.
Now the two companies have separate AD – exchange - domains – DHCP remote desktops etc and I am thinking on the best way of getting them working causing last disruption as possible.
In normal circumstances I would have created a trust between the two domains, create a new domain and migrate the AD to the new domain, gradually move the remote desktop , connect the branch offices and get them migrated in stages.
This is not feasible, as they want to move and work as the new company in two months. I need to start get things sorted so that they are ready for when they move company B in to company A ?
Any pointers on where to start?
Ie what can I do with the AD ? will it be wise to move both company to a new domain so then when we move the workstation they can login to the new domain.
Is there a way to get the two exchange server and mailboxes ready so that we can redirects emails to a single exchange and point the mx records to that server ?
Company A points to remote desktop for some offices, Company b point to remote desktop for some other offices, i woud need to create a new remote desktop server ( but that implies that all the apps and services have been moved. )
Is there a way of running two domains from the same office ( ie keeping the company A - and company B separate ) but in the same building ?

Thanks
Stef

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

@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

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