Home Forums Discussions Feedback and Recommendations Cloud hosting of SQL

I am planning to have second office at remote area. I have been using dropbox as clouding host for my personal data. If AC allow to use SQL cloud hosting service (3rd party companies), all my headache using server based AC is going to be solved.

- SQL database/imported items are all synchronized and saved in each computer hard disks in which cloud software (just like dropbox) is installed.
- No worry of back up : synchronized data, saved on multiple computer.
- Each office will own servers but the data are synchronized almost real time.

I will try with dropbox as I just increased dropbox size to 100 Gbytes with $20/month.
But I do not know how to use SQL in dropbox (it was not working). Probably AC may have to allow this functionality.

Alan.

If you want to host AC so you don't have to host it yourself, you should talk to Indy.

JamesNT

Have you considered using a Terminal Server? That's essentially what hosted services are. They run a terminal server and you remote in. You can install one at your current office.

I don't how realistic real time synchronization of SQL is for a small office. I believe it's called transactional replication and requires a pretty steady connection. Not business class cable, but more like T1 line.

I think you're mixing up 2 things here. A hosted AC solution and the DropBox sync are two radically different solutions. You can't just sync the database with DropBox because it's being used. It probably won't sync until you shutdown the SQL server. A hosted AC solution would mean some third party provider would be hosting your database. There are hosted SQL services, but say good bye to AC support.

I'm just going to dip in here [as my Grandmother would say, were my ears burning?] and agree that Hosting SQL, using Dropbox, Hosting AC, and a managed service that includes AC are all veeery different.

From what you have described, I think you are looking for one of the last two.

I'm also going to agree that there is NO WAY DropBox [or any other type of cloud drive] is going to do what you want, and there is a fairly good chance that it will corrupt your database if you keep trying.

And Indy would you disagree with this?

AC Support pretty much don't want you using anything other than SQL Server 2005 Express. You'd need something like SQL Azure as a cloud service: http://www.windowsazure.com/en-us/home/features/sql-azure/

I'm sure MS will have no problem keeping their side active, but you always have to invest in solutions that will ensure your internet connection as well. Which will probably involve getting a T1 line at each office. Which are pretty damn expensive. 300-400/month usually.

Honestly, I would just get Windows 2008 R2 Server and a few RDS Cals and with a proper setup you can just use RemoteApp to fire up amazing charts from the second office. Go to your domain.com and sign in using username and password and see published apps and click on Amazing Charts. AC fires up and looks like a app on the remote computer, and what I mean by that is your not getting the remote computers desktop as well as the computer your sitting at's desktop so all you see is the AC app.

It's basically like working though remote desktop only with RemoteApp it feels like the app is installed locally, sorta like Citrix XenApp (Metaframe) if your familiar with that.

The MS solution tends to be quite cheaper then Citrix.

I would get a decent server with 2008 R2 (R2 is a must for RemoteApp) and then purchase RDS Cals though SoftwareMedia.com or your favorite place http://www.softwaremedia.com/licens...ows-remote-desktop-user-cal-with-sa.html (Formally Terminal Services CAL -- Now RDS CAL) 5 Minimum on Open License but you can buy individual licenses (retail box).

I think you will find this to be a decent solution, probably very similar to how AC is doing their "Cloud" service, which I suppose you could wait for (if its not ready now).

So you have your main server in one office and the other office hits a webpage and signs in with Username/Password, Click on AC and then signs in again with the AC credentials. AC is presented to the remote computer like it was installed.

(Some port forwarding on your firewall/router is required) 80, 443, and 3389 need to be forwarded form the server to the outside world. And you probably want a static IP but you could use a Dynamic DNS servers like afraid.org (which remains free).


If you want more info, let me know.

As Christopher suggests, using a Terminal Server is the way to go. You can configure Remote Access to just use port 443. Ports 80 and 3389 are not necessary to open. Not opening them reduces the amount of attack vectors into your server. If you add the Remote Desktop Gateway sub role, then it'll be authenticating against the gateway and you can access all computers on your network including the server without having to open port 3389.

I expected that Sandeep would weigh in again, and clarify what he was thinking.

He is correct that AC support is not going to offer support for a full SQL instance, where-ever it is located.

That being said, I haven't found the top-end for how many users a real server will handle, but the more users you add, the slower SLQ Express goes, as it is working within that 1G memory footprint.

Agree with reducing the attack surface. Go one better and configure a random high port and port forward that internally to 3389. You have then greatly reduced the brute force attacks that machine will see.

To add to this. The above step would only be necessary if you're using Remote Desktop directly. In your routers (i.e. D-Link, Linksys, etc.), in the port forwarding table, there will be an option for a Public Port and a Private Port. The public port would as Indy pointed out a high number like 11000-62000 (I can't remember the exact range, but you got a lot of choices.) The private port would be 3389. If a person were to remote in, you would have to tell them to specify the port number when remoting in. Assume your IP address is 67.67.67.67, the public port is 32000 and the private port is 3389. You'd tell the person who's remoting in to put 67.67.67.67:32000 as the computer name in Remote Desktop

With the gateway, it's sort of like Remote Desktop VPN. Once you authenticate against the gateway, it's like you're on the LAN there. No ports need to be opened/forwarded externally besides 443 for SSL. This uses an encrypted SSL connection to authenticate (the same kind used for credit card transactions online). You can use a $50 GoDaddy SSL Certificate.

1. Has anyone tried using JungleDisk for AC, which basically is like a cloud disk drive on your desktop.

2. I use Remote Desktop through SBS2011, it works well but I have been unable to use local computers wit the remote desktop. does anyone know how to do that?

It is funny how often we talk about and recommend Terminal Services. Chris spells it out nicely. I can't see another way to go if you need to remote from another office.

As far as RDC, 3389 does not need to be used at all. 3389 is the worse port for security holes in your network. This is a brief paragraph on RDC with SBS 2008 and 2011, not able to use in 2003. It doesn't work well with the regular servers, although Microsoft does provide for that:

[note: TS = terminal services, RDS = Remote Desktop Services, same thing they just changed the name with 2011]

SBS 2003 /2008 / 2011 / SBS 2011 Essentials / Home Server / Home Server 2011 / Windows Storage Server Essentials 2011 all have Remote web workplace which allows you access to the server through SSP (port 443) so you don?t need port 3389. Much more secure for a few reasons.
I don?t know about the others but SBS 2008 and 2011 also allow you to do direct access with the remote desktop client through port 443 using the TS/DRS gateway service. For the record with SBS 2011 doing so require each user have an RDS CAL.

Server standard; 2003 / 2003 R2 / 2008 / 2008 R2 do not have the same luxury, however if you make any one of those a TS/RDS server you can also add the TS/RDS gateway service to allow access to it my means of TS gateway. The TS Gateway allows SSL/443 access to any server or PC on the network.

Microsoft Licensing is a bit confusing so I thought I would try to clarify this part. If you access the Remote Desktop Gateway through Remote Web Workplace, then you do not need an RDS CAL. However, if you choose to access the Remote Desktop Gateway directly, then you will have to buy an RDS CAL. (This is how they make their money haha). So if you use the website (RWW) to login, you're fine. If you want to save that RDP file to your desktop, you're technically in violation.

Bert,

I'm going to have to disagree with you. Terminal Services on port 3389 is perfectly secure. You can set the encryption to high which uses 128-bit encryption with connections to clients and you'll be fine. Strong user passwords, which you should be using regardless, will stop the dirtbags from guessing an account password and hacking your box. The NUMBER ONE REASON behind Terminal Services Gateway is so you can run Terminal Server over port 443 to get past firewalls. Many hotel firewalls allow only port 80 and 443 traffic (HTTP and HTTPS respectively) so people could not log on to work using port 3389. This is the same reasoning behind using DirectAccess as opposed to dial-up VPN. DirectAccess is VPN over port 80/443.

Sandeep,

I'm going to have to disagree with you as well. Licenses are NOT required for Remote Desktop Services Gateway. The RDS Gateway is just a connection proxy, that is all. You have to have CALS for the Terminal Server/Remote Desktop Server you are accessing behind it. So if you have 50 users that need to log on to a Remote Desktop Services server, you need 50 Terminal Server CALS and you're done. You do not need CALS for the Gateway regardless of whether you use RDP or RWW.

JamesNT

And I am disagreeing with ALL of you.
If you want to be in the cloud, call Indy and let him handle the ports and licenses.

That's exactly what I thought, but I found out I was wrong. Technically, SBS Users are only licensed to use the Gateway through RWA. What you're saying may be true for Server 2008R2, but not for SBS 2011. That's why you don't have access to the console in SBS. If you do directly access a desktop using the Gateway then you need an RDS CAL. Even physical desktops in your LAN, not even talking about RDS right now.

Read this: http://blog.mpecsinc.ca/2011/07/sbs-2011-remote-desktop-gateway.html
and this: http://msmvps.com/blogs/bradley/archive/2011/08/13/rds-in-sbs-2011.aspx

I don't understand the logic behind it, but it does give MS more money.