Hey all I am in need of some help setting up TFS on my Azure windows server 2016 VM.
I think i have all my firewall rules set up but i'm not that sure if i do or not. I followed this site as an example.
However, I am not able to reach it outside of my server using my domain name like so:
http://mydomain.me:8080/tfs
I have also tested out my connecting outside of my server for my SQL 2017 and it seems i cannot connect to that either.
What am i missing in order for me to connect to both the SQL and TFS from outside the server?
Firmware rules are not enough to access TFS set up in Azure. The basic topology looks something like the illustration below:
In a virtual network, it establishes a new domain with two domain controllers and deploys a TFS server, a database, and a TFS agent. To access the virtual network, the pattern includes a jump box; another strategy would be to add a VPN gateway, but for simplicity we are going with the jump box.
You can check the blog below for more information:
https://blogs.msdn.microsoft.com/mihansen/2017/11/15/private-tfs-deployment-in-azure/
Or you could consider migrating to VSTS as #Daniel's mentioned.
How can I deploy Access applications to multiple companies, with linked tables to SQL Azure servers?
I'm planning to deploy the Access programs with Microsoft Access runtime, and I'm assuming that I'll need to include the odbc drivers as well? Is there a way to automatically have Azure create a new server when a company signs into my website and downloads a program, and have the Access program link to it? And is there a way to get around the IP address settings in Azure as well? Because companies will be using the programs on multiple PCs. Or is it possible to utilise that and charge per PC?
If you distribute the application pre-linked, then the user should not have to do anything to consume the data.
When using Access with SQL server you can in general use the standard windows built in SQL driver. However in the case of Azure you do need to download + install the native 11 drivers (so I recommend you use that driver during development and setup).
You can also have code include to re-link to the sql server, but as noted, if your application is “already” linked, then you really don’t have to do anything on application startup. Such re-linking would not be required every time the application starts, but only a “one time” re-link is required say if you’re going to change the database, or perhaps the user logon. How to re-link (DSN less) is outlined here:
http://www.accessmvp.com/DJSteele/DSNLessLinks.html
As noted, you really don’t need the above.
As for IP restrictions, in the Azure setup you can turn off such restrictions if you need a connection that will occur from any location, but that does open up a security hole. (when you first create the SQL database you will be prompted for firewall rules).
All of the above assumes you been developing that Access application with SQL server as the back end (you can even use the free edition of SQL express for development on your local machine).
Last but not least:
Because your connection is occurring OVER the internet, then you speed will be MANY times slower then using a local server. Read the following article to get a “grasp” of this speed difference:
http://www.kallal.ca//Wan/Wans.html
So MUCH additional work is required in Access to obtain good performance when your connection is OVER the internet as opposed to SQL server running on your local network.
I've been given a VM for development purposes, in which is installed Windows 2008R2, CRM 2011, SQL Server, etc. Prior to me being given the project, the VM was being used inhouse, validating to the company's AD server.
Since I need to use the VM off-site, I have run "dcpromo" in order to install Active Directory etc. in the VM. As you may have guessed, upon doing this, nothing can now connect to SQL Server using Windows Authentication, because users are now AD users, with different IDs (at least I assume that's the problem - I'm no sys admin).
So when I run CRM Deployment Manager, it says it can't connect to the CRM_CONFIG database, assumedly because Windows Auth isn't working. SQL Server is running fine. In fact Windows Auth won't even work in SQL Mgmt Studio, I have to connect using SQL Server Auth.
How do I fix this mess? :) Is there a way of telling CRM Deployment Manager (and everything else) to use SQL Server Auth instead of Windows Auth? Or is there a way to fix Windows Auth on the machine? The latter would be preferable, as it would probably fix everything which now can't connect to SQL Server with Windows Auth.
I'm not sure how to fix this, but I would probably have a go at:
Uninstall CRM
Reinstall CRM - these steps should give you a working CRM, without any customisations or data.
Import the existing organisation - this should give you CRM as the original developers had it (as part of the import process you can remap all the users in AD).
Check out this link for detail on the process:
Import a Microsoft Dynamics CRM 2011 Organization
Also this may help:
Move the Microsoft Dynamics CRM 2011 deployment
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).