I have a number of VMs under one domain. I am setting up kerberos and a part of it is installing the Azure AD App Proxy connector. I have installed the connector in one of the servers but the application that I published is in a different server. Would this still work or I need to install the connector to the specific server where the published application is?
The connectors must be installed on a Windows Server that has access to the backend application
Install the connector on a machine running Windows Server 2012 R2 or later. The connector needs to communicate with the Application Proxy service and the on-premises applications that you publish.
The windows server needs to have TLS 1.2 enabled before you install the Application Proxy connector
If you are installing the connector on Windows Server 2019, you must disable HTTP2 protocol support in the WinHttp component for Kerberos Constrained Delegation to properly work. This is disabled by default in earlier versions of supported operating systems.
You may refer this for more information https://learn.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy-connectors
Good morning. I recently installed Windows Server 2019 on Google Cloud Compute Engine and in there I installed a copy of 5 user copy SAGE 50 Premium 2020. I have given the server a static IP, and I have shared the Peachtree/Company folder on the Windows Server 2019, but I don't know how to access this shared folder from my Laptop or other desktops in the office. The local Sage installations in the office require access to this folder that is on the Windows Server, on the Compute Engine.
I read in some places that we require a VPN but even that I'm not sure how to set up withing the cloud.
Yes, you can connect your on-premises network with your cloud VM via VPN tunnel and then you'll be able to use windows sharing options.
Have a look at Google Cloud VPN. Also, you can check available option at Marketplace using keyword VPN in case you prefer or more familiar with other VPN solutions like OpenVPN. Don't forget to setup your firewall and routing options accordingly to the documentation of selected VPN.
I have two solaris servers.
One server is for clearcase licenses and another is for source code repository.
Unfortunately, somehow licensing server is not working with telnet (its running in single user mode).
As a result, I cannot open ClearCase Explorer as the licensing server is not working.
Now, I wanted to get the sourcecode from the repository server to my local (windows) system.
How can we get that?
We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.
Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?
This is what I came up with. Unfortunately, all of these seem to have drawbacks:
SQL Server Compact Edition: Does not support views.
Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.
SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."
SQL Authentication: Microsoft says: "When possible, use Windows Authentication."
Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...
The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.
EDIT: Some clarification: It's a "local" application, i.e., the SQL Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.
#Heinzi write:
Using Windows authentication and
granting BUILTIN\USERS full access:
This is by far the easiest solution,
but somehow it "seems wrong" to do
that...
The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.
How about:
Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
Call sp_setappprole to "elevate" the client connection to your defined application role's identity.
If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.
I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.
I have write a scripts they are a combination of VBA and VBScript.
Ask
Is the DB and App to run on single computer or different computers.
If different computer what is the name of the computer the DB is located on.
Is the DB and App to in a workgroup, homegroup or domain environment
Is the DB computer already have SQL Express or above
Is the App computer already have Access or Access Runtime installed.
If yes which version.
Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data.
Does this group already exist
If No List the Name of the Users that Should Be Added to the Group
Also questions about the Admin Users and Group
The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.
I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.
If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.
I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.
When I am up and running I will make the platform available to others.
I'm not sure whether I'm asking the question correctly, but I've been told SQL Server cannot run on a Novell server. Is this true? If yes, why not?
Your problem is your directory service, whether it's Microsoft's Active Directory or Novell's Directory Services (I think it's called).
Sounds to me like your DNS is broken if your clients can't resolve names to IP address.
NOW I see your problem! Sorry dude!
Yes, VERY easy. Kinda.
SQL Server used to be able to talk IPX (the netware protocol) but I think Netware will now talk TCPIP, and you can run IPX and TCP/IP on the same network without an issue - windows clients can run both at the same time, 99% of routers handle all protocols etc.
Windows (XP/2003/etc) can run the netware client, so it can talk to shares etc.
Use the SQL Server logins (rather than windows integrated logins), and it'll work from anything - we have Java on Linux talking to SQL Server on windows just fine :) It's all in the connection string: userid=username;pwd=whatever;server=yourserverhere; etc. But you MUST use the SQL Server Configuration Manager to set these up - the default is shared memory, so you have to enable TCPIP etc.
You may have to be more specific about what a "novell server" is. From what I understand, Novell servers run some form of Suse linux. Sql Server is a windows only product.
My company, however, does have clients that run Novell networks, and we do run Sql Servers on their network. But they're hosted on a win box...
SQL Server is a Windows app. Novel is either one of:
Novell
or
Linux
Neither of these are windows :) It's like asking "why can't I run this Mac application on my windows box". Or "why will my petrol car not run on diesel?"
There are old version of Sybase, which SQL Server sprang from, which COULD run on Novell Netware, but you'd need to find a software museum to find one, I think!
If you need a SQL Server, I'd suggest you either get Small Business Server, which comes with MSSQL, or install one of the free editions of SQL Server on XP or windows 2003 server. Or use something like MySql, Postgress etc on Linux.
I'm not sure what you are asking. Are you looking for software to allow NetWare applications to talk to a SQL Server running on Windows? The wording of your original question implied that you want SQL Server to run on the NetWare machine.
The question of why SQL Server doesn't support NetWare is best asked of Microsoft, but AFAIK SQL Server doesn't support any non-Windows OS.
As someone else said, SQL Server originally came from Sybase's SQL Server (now called Adaptive Server Enterprise), which supported NetWare at one time but dropped it a long time ago. Sybase's other RDBMS, SQL Anywhere, dropped NetWare as of version 11, but versions 9 and 10 are still supported on NW.
OK, now I think I understand. I was thinking "client" as in database client application, not the Novell client.
I don't think you'll need the Novell client on the Windows machine, for a couple of reasons:
If the client is trying to connect over TCP/IP, it doesn't matter whether or not the Windows machine has the Novell client installed
Windows shares aren't affected by the Novell client, though you need some kind of Novell client for the Windows machine to map NetWare volumes
If the Windows machine does need to map NetWare volumes, I have found in the past that the Client Service for NetWare service (which ships with Windows but isn't installed by default) is sufficient, and doesn't have all the overhead of the Novell client.
It sounds like your Windows SQL Server is in fact a second class citizen on your networks. (I imagine you are using SQL Authentication instead of AD based.) If you have to connect via IP rather than name, then your Windows boxes aren't participating in an Active Directory authentication + DNS setup like is the case in most "windows" networks verus the "netware" network that you are running into. Netware has it's own form of directory services that is independant of Microsoft.
If you want your Microsoft SQL Server to be a integral part of your network, then you need Microsoft Active Directory installed with integrated windows authentication and DNS services running on a Domain Controller. But, this would conflict with your directory services (if used) on your netware server.
If your Netware network is running just fine, then I wouldn't change it. Simply add the microsoft sql server's network name to your local DNS services and it won't appear like it's a second class citizen. You could install the netware client on the SQL machine but that would make most DBA's cringe. But, it would register the machine in Netware's directory.
SQL Server, although rooted in a Sybase/Unix/VMS background, is a native windows application. Apart from the compact edition (which runs on some Windows mobile platforms), SQL Server runs on Windows desktop and server operating systems.
More informaiton can be found at wikipedia.
Sorry to be prickly, but I'm not a noob: I know you can't install SQL Server on Linux. Do you guys have customers running Netware trying to connect to a SQL Server? That is what I am dealing with.
We have customers, mostly school systems, that use Netware as the "network OS" with many Windows workstations running the Netware client. Our app uses SQL Server which is usually installed on a Windows 2003 server, but the server is always a second class citizen on the network. Users often must use the IP address rather than machine name to connect the SQL Server.
#Will: Do your Novell customers have trouble accessing SQL Server on the Windows server? Can you install the Netware client on the Windows server to enable file sharing?
#Graeme: Thanks for helping me refine my question. My employer somehow has the impression that a Windows server is a second-class citizen on a NetWare network. Would installing the NetWare client on the Windows server make it easier for NetWare clients (with some form of Windows OS) connect to the SQL Server? Would installing the NetWare client on the Windows server allow the server to share directories and files like a Novell server?
#geoffcc: The app uses SQL Authentication to connect to SQL Server.
The core issue is how are you authenticating to the SQL database. If you have an Active Directory tree, and an eDirectory you can easily link the two via Novell Identity Manager, which will synchronize users, groups, etc (any object you care to map between the two systems) as well as passwords.
Thus the same object exists in both locations so each system can use it as much it needs too. The license for Identity Manager is included with the Open Enterprise Server license (OES can run on Netware or on SUSE Linux Enterprise Server (SLES)).
Then you could use the Active Directory integrated authentication.
Beyond that, your Netware server likely does not need to connect to the database directly. If it does, you will be writing or using an application that includes the database connectivity. At which point it becomes a question of is there a client for this OS or not.
#flipdoubt Well if you are using SQL Authentication, then you are using a SQL Client of some kind to connect to it, and the fact you have Novell in the picture is as unrelated as if you had Banyan Vines. (There you go! Now a search will show at least ONE reference to Banyan Vines!! Every good technology site needs at least one, and probably not more than one!)
As others have noted, what are you trying to do?
If they need to use the IP address of the SQL server to connect to it via a SQL client, then you have a DNS problem.
If you want to connect to the MS SQL server box to put a file on it, then that is somewhat unrelated to the SQL aspect of the issue. There again, DNS can solve your woes, if you register the name of the server (Say it is SQLSERV1) with the default DNS name (say acme.com) tacked onto the end of it, so that the IP Name sqlserv1.acme.com resolves to the IP Number you want it to point at.
Next comes the question of where are the user identities stored? You are using SQL Authentication, so that means you are creating accounts in SQL for each user.
The basic alternatives are to use Active Directory and have MS SQL server use those identities. If you are in a non-AD shop, you can investigate Novell Identity Manager product which has a JDBC driver that can do a fair bit, One thing it can do is synchronize users from eDirectory to be SQL Server users. (Or to Active Directory, Lotus Notes, most LDAP directories, AS400's, mainframes, NIS/NIS+ and many more systems).