Skip to main content

Connect and Use a SQL Server Node

Use this guide after you launch a Windows SQL Server node from MyAccount. A SQL Server node is a self-managed Windows node where the selected image or plan includes Microsoft SQL Server. It is different from E2E Managed DBaaS, where E2E manages the database service layer for you.

For the basic Windows login flow, see Connect to a Windows node. This page adds the SQL Server-specific steps you need after RDP access works.

Before You Begin​

Make sure you have:

RequirementWhere to check
SQL Server nodeIn MyAccount, go to Compute > Nodes and confirm the node was created from a SQL Server image or SQL plan.
Node statusThe node should be in Running state.
Windows accessRDP must work on TCP 3389.
PasswordUse the secure password email sent after node creation, or the latest password if changed later.
Network pathUse a primary public IP, Add-on IP, VPC/private IP, VPN, bastion, or another reachable path.
Security groupAllow only the required inbound ports from trusted source IPs.
SQL clientUse SQL Server Management Studio, sqlcmd, an application driver, or another SQL Server-compatible client.
Best Practice

Avoid exposing SQL Server directly to the internet. Prefer private connectivity between application nodes and the SQL Server node. If remote SQL access is required, restrict TCP 1433 or the actual SQL Server port to trusted source IPs only.

If you have not created the node yet, go to Compute > Nodes and start the create-node flow. In the CPU operating system choices, select the SQL Server image that matches your workload, such as SQL Web or SQL Standard, if shown. See Create a node for the full creation flow.

note

SQL Web and SQL Standard are different SQL Server edition choices. Review your license and workload requirements before launch.

Find the Node IP Address​

  1. Log in to MyAccount.
  2. Go to Compute > Nodes.
  3. Find the SQL Server node.
  4. Copy the primary public IP, Add-on IP, or reachable private IP.

Connect to the Windows Node​

  1. Open your RDP client.
  2. Connect to the node IP.
  3. Enter the username and password from the node password email.

If RDP fails, fix Windows access before troubleshooting SQL Server. Most first-access issues are caused by a missing public IP, an unreachable private network path, TCP 3389 blocked in the security group, or an incorrect password.

See Connect to a Windows node for the full RDP flow.

Verify SQL Server Locally​

After you sign in with RDP, verify the SQL Server service from inside the node before allowing remote database access.

  1. Open SQL Server Configuration Manager or Windows Services.
  2. Confirm the SQL Server Database Engine service is running.
  3. Open SQL Server Management Studio if it is installed.
  4. Connect to the local SQL Server instance from inside the node.
  5. Confirm the SQL Server edition, instance name, and authentication mode you plan to use.
  6. Create or verify the database, login, and permissions required by your application.

In SQL Server Management Studio, use the local instance first:

Server type: Database Engine
Server name: localhost
Authentication: Windows Authentication

If localhost does not work, try ., 127.0.0.1, or the Windows host name. You can find the host name from Command Prompt:

hostname

For a named instance, use the instance name shown by SQL Server services, such as:

localhost\SQLEXPRESS
localhost\INSTANCE_NAME

After connecting, use New Query to confirm what SQL Server itself is running:

SELECT
    SERVERPROPERTY('Edition') AS Edition,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel,
    SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel,
    SERVERPROPERTY('EngineEdition') AS EngineEdition,
    SERVERPROPERTY('MachineName') AS MachineName,
    SERVERPROPERTY('ServerName') AS ServerName;

The Edition value is the clearest confirmation of whether the node is running SQL Server Web Edition, SQL Server Standard Edition, or another installed edition. Do not rely only on the node name, image name, or plan label when you need to verify the actual edition.

If SQL Server Management Studio is not installed, use sqlcmd if available:

sqlcmd -S localhost -E -Q "SELECT SERVERPROPERTY('Edition') AS Edition, @@VERSION AS VersionInfo;"

To check whether SQL Server services are running, use PowerShell:

Get-Service *SQL*

For a default instance, look for MSSQLSERVER. For a named instance, look for MSSQL$INSTANCE_NAME, then connect with localhost\INSTANCE_NAME.

Decide How Applications Will Connect​

Choose the access model before opening database ports.

Access modelBest forWhat to configure
Local onlyApplication and SQL Server run on the same node.No public SQL port required. Connect with localhost or the local instance name.
Private networkApplication nodes connect to SQL Server inside VPC or private networking.Allow SQL traffic only from private CIDR ranges or application-node security groups.
Restricted public accessTemporary administration or a trusted external application path.Allow SQL traffic only from specific source IPs. Avoid 0.0.0.0/0.
RDP administration onlyYou administer SQL Server from inside the node.Keep SQL Server ports closed externally; use RDP to manage the database.

For most production deployments, keep SQL Server private and place application nodes in the same private network path.

Allow SQL Server Connections Only If Needed​

SQL Server default instances commonly use TCP 1433, but the actual port can differ for named instances or custom configuration. Confirm the listening port before changing security rules.

If external or private-network SQL access is required:

  1. On the SQL Server node, confirm the SQL Server instance is running.
  2. In SQL Server Configuration Manager, confirm TCP/IP is enabled for the instance.
  3. Confirm the TCP port used by the instance.
  4. If you changed SQL Server network protocol settings, restart the SQL Server Database Engine service.
  5. In Windows Firewall, allow the confirmed SQL Server TCP port only from trusted sources.
  6. In MyAccount, update the node security group to allow the same port only from trusted source IPs or private ranges.
  7. From the client machine or application node, connect using the node IP and port.

Connection examples:

<private-ip>,1433
<public-ip>,1433
<private-ip>\<instance-name>

For named instances, SQL Server Browser may use UDP 1434 to help clients discover the instance port. Use a fixed SQL Server port where possible so you can keep firewall and security group rules narrow.

warning

Opening TCP 1433 in Windows Firewall is not enough by itself. The MyAccount security group, Windows Firewall, SQL Server network protocol, SQL Server service status, and route to the node must all allow the connection.

Security Checklist​

After the database is reachable:

  • Create application-specific SQL logins instead of sharing administrator credentials.
  • Use strong passwords and rotate temporary credentials.
  • Restrict SQL Server access to application nodes, VPN ranges, or trusted administrator IPs.
  • Keep RDP restricted to trusted source IPs.
  • Keep Windows and SQL Server patched.
  • Monitor CPU, memory, disk, and database growth.
  • Back up databases before major schema, application, or configuration changes.
  • Test restore steps before relying on backups for production recovery.

For node-level backup behavior, see CDP Backups. For database-level backup strategy, use SQL Server-native backup and restore practices appropriate for your edition and workload.

Important Notes​

Saved Images​

MyAccount blocks saved image creation when an MSSQL license is attached to the node. If you click Save Image for an MSSQL-licensed node, the portal shows an informational message instead of starting image creation.

This limitation is license-related. Use database backups, node snapshots where appropriate, or support guidance instead of assuming a SQL Server node can always be converted into a saved image.

SQL Server Edition​

The portal plan selector can show SQL Server version information for SQL image plans. Use the version and edition shown in the portal as the final choice before launch. Do not rely on static documentation for currently available SQL versions or prices.

After the node is running, confirm the installed edition from SQL Server itself using SERVERPROPERTY('Edition'). This matters when the node was created from a SQL Web or SQL Standard image path and you need to verify the actual database engine before using it for a workload.

Security Groups and Windows Firewall​

MyAccount security groups control network traffic before it reaches the node. Windows Firewall and SQL Server network settings still apply inside the node. A successful setup requires all three layers to agree:

  • MyAccount security group
  • Windows Firewall
  • SQL Server network protocol and port

Common Connection Problems​

ProblemLikely causeWhat to do
RDP cannot connectTCP 3389 is blocked, the node has no reachable IP, or the route is unavailable.Fix RDP access first using the Windows node guide.
SQL client cannot connect from another machineSQL Server port is blocked, TCP/IP is disabled, the wrong port is used, or the security group does not allow the source.Test locally, confirm the listening port, then update Windows Firewall and security group rules.
SSMS cannot connect to localhostSQL Server may use a named instance, the service may not be running, or Windows Authentication may not be enabled for that context.Run Get-Service *SQL*, confirm the instance service, then try ., 127.0.0.1, the host name, or localhost\INSTANCE_NAME.
sqlcmd is not recognizedThe command-line SQL Server tools are not installed or are not in PATH.Use SSMS if available, install the required Microsoft command-line tools, or use another supported SQL Server client.
server was not found or was not accessibleInstance name, IP, port, route, service status, or SQL Server protocol is wrong.Verify instance name, service status, TCP/IP, and port from inside the node.
Login failsThe SQL login, Windows login, authentication mode, or database permission is wrong.Connect locally as an administrator, verify login type, then grant only the required permissions.
Save Image is blockedThe node has an attached MSSQL license.Use database backups or contact support if you need assistance with migration planning.
Port 1433 is open but connection still failsThe SQL Server instance may use another port, Windows Firewall may block it, or SQL Server may not listen on TCP.Confirm the actual SQL Server listening port and protocol settings.

Automate This​

Use the approved MyAccount API docs for node operations:

The public API describes the supported fields for creating and managing nodes. Treat unpublished or portal-only fields as implementation details unless they are present in the approved public API documentation.

For SQL Server administration after the node is created, use Microsoft-supported SQL Server tools, drivers, and automation for your SQL Server version.

ResourceUse it for
Create a nodeLaunch a SQL Server node from the Windows SQL image path.
Choose a node familyDecide whether SQL is the right node family.
Connect to a Windows nodeUse RDP to access the Windows server.
Security GroupsRestrict RDP and SQL Server ports.
VPCKeep application-to-database traffic private.
Static Public IPsManage primary public IPs or Add-on IPs when required.
CDP BackupsReview node-level backup behavior.
Managed DBaaSUse managed databases instead of self-managed SQL Server nodes.
Microsoft SQL Server connectivity troubleshootingTroubleshoot SQL Server client connection errors.
Microsoft SQL Server firewall guidanceReview SQL Server ports and Windows Firewall behavior.

Next Step​

After SQL Server is reachable from the intended application path, create the application database and user, restrict access to only the required source IPs or private ranges, and take a database backup before loading production data.

Last updated on May 19, 2026.