I have created an application which is an window service which has to run under context of domain administrator account and take some server settings etc stuff.
Now I need to install it on client machine, obviously I can not do it using normal deployment project MSI because it involved custom dialog and user input while installation.
How can I do this?
Now Is there any 3rd party framework which really allow me to create custom dialog and write code which will execute at runtime?
If I have to do it manually? How I will incorporate my custom installer files and my windows server application files into a single MSI.
This is how I want to have my installation process:
Welcome Screen
System Checks
EULA
Server settings as per product licensing, its a radio selection by user.
Server settings based on last selection.
my window server settings which will make a rest call and update server.
accepting domain user account credentials.
Now installations starts.
Redirection to cloud portal with finish message based on selection.
What you need is supported by MSI installers, but mostly by commercial setup tools. The server communication is usually done through built-in support or through custom actions.
Here is a list of setup tools which can get you started: http://en.wikipedia.org/wiki/List_of_installation_software
For example, Advanced Installer has built-in support for server-side license validation and communication.
Pick a setup tool and try to create your installer. You can then ask more specific questions if you encounter any problems.
Related
We recently created a windows login (domain\etluser) with read-only access to different SQL Server databases. Is there anyway developers can use that generic account to develop SSIS packages using Visual Studio?
It require us to create OLEDB connections using that new account, but couldn't find an option for that
I heard that it is possible to run packages as another user or proxy from SQL Server integration services, once the development and testing is over: How to schedule SSIS package to run as something other than SQL Agent Service Account
In windows, I am aware of two mechanisms to start a process as another user. From the command line, you can use RunAs
As a consultant, I often bring my own device to clients and then use Runas to impersonate my client-domain account without having to get my laptop's domain trusted by their corporate domain. I have a folder filled with batch files that launch a program with their credentials. For example, this is my script to start Visual Studio 2017 Enterprise Edition as my "other" self.
runas /netonly /user:domain.com\billinkc "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE /nosplash"
I've not done SSRS development in a long while, but 2014?ish at least this approach would allow me to develop reports but I could not preview the reports within VS as the preview process would get launched as a "new" process which inherits my current credentials instead of the ones I was started the parent process under. SSIS dev though, worked just fine with this approach.
The biggest complain I have with either approach is that I have to type the password every time. You can't redirect the input from elsewhere and you don't see the typing so you can't tell how many characters you've typed if you screwed up the password. Couple that with an aggressive lockout policy and I spent a lot of time at one client twiddling my thumbs waiting for my account to unlock.
The other approach is a GUI approach. In Windows Explorer, shift right-click on the executable and you should be presented with a context menu like the following.
Pick "Run as different user" and you'll be prompted with a more friendly window to enter credentials
With Runas, you could at least prepopulate the user to save a few keystrokes but with the GUI approach, you have to enter everything every time.
If you run your SSIS jobs through the SQL Server Agent, you can use Proxies: https://learn.microsoft.com/en-us/sql/ssms/agent/create-a-sql-server-agent-proxy?view=sql-server-ver15
There's a couple steps involved:
Create a user for your dom\etluser on the SQL Server, in Security \ Credentials
Create a proxy in the SQL Agent using those credentials, and authorize it to run SSIS jobs
Create a job (or edit an existing job), with the SSIS package as a step and on that step set 'Execute As' to the proxy.
I am using Visual Studio 2015 with SSDT to develop reports with Report Services project. I would like to create Shared Data Sources that use "Windows Authentication with a specific user name and password" in this VS SSRS project, (not "Windows Authentication with integrated security", which authenticates as my user account).
The data source is setup the desired way on the report portal already ("Windows with stored USER and PWD"). But I want it configured this way in the Visual Studio project so that all developers can open the project & develop with the data source connections, and also so that deployment of the project files to the server is more accurate. I don't want to have to deploy it with "Windows integrated" then go the portal and manually configure the Shared Datasource-- that is a more error-prone deployment method.
It looks like the "Data Source Properties" screen is very similar for Report Builder and Visual Studio-- except Visual Studio is missing the missing the "Use as Windows credentials" checkbox option.
Does anyone have an answer for this Visual Studio option on the Data Source Property for "Windows Authentication with a specific user name and password"?
****Here are some screenshots:****
VisualStudio-SharedDatasource-Properties.png --> option missing
VisualStudio-Datasource-SQLServer-AuthenticationOptions --> We are not using SQL Server User in our environment, it is Windows user.
ReportBuilder-rdl-Datasource-DatasourceProperties.png --> option is there
ReportPortal-SharedDatasource-Properties.png --> option is there
Hi #SherlockSpreadsheets,
I can bring you a workaround: Choice "Windows Authentication" and then add the required credentials at Credential Manager with the below steps:
Open Control Panel.
Open User Accounts.
Click Manage My Network Passwords on the Related Tasks panel (on the
left side of the window). You'll get a dialog box listing all of
your stored usernames and passwords. Add another username and
password, or remove the existing ones or change their properties.
I am currently trying to create a release to a windows server from TFS 2015. I'm trying to figure out if there is a way to pass my user credentials from TFS to the server I need to access without hardcoding them into the release arguments. The way I hope to have it work is that whenever a user queues a new release, their credentials are used for the server login. If they aren't in the correct AD group for the server, the release should fail.
I can't find any way to pass user credentials from TFS to the server. You may create a test account for the server, and use this single test account for deployment. Then define it under configuration variables in your release definition:
In this way, you can use these values in the steps instead of typing them:
after install the software in the client machine i wan to send the next updates to client machine,how i send like a patch file and install automatically in the client place,can one give some idea about this...
ClickOnce is designed to ease the deployment of windows forms app. Check it out here
From that link:
ClickOnce is a deployment technology that enables you to create
self-updating Windows-based applications that can be installed and run
with minimal user interaction. ClickOnce deployment overcomes three
major issues in deployment:
Difficulties in updating applications.
With Microsoft Windows Installer deployment, whenever an application is updated, the user
must reinstall the whole application; with ClickOnce deployment, you
can provide updates automatically. Only those parts of the application
that have changed are downloaded, and then the full, updated
application is reinstalled from a new side-by-side folder.
Impact to the user's computer.
With Windows Installer deployment, applications often rely on shared components, with the potential for
versioning conflicts; with ClickOnce deployment, each application is
self-contained and cannot interfere with other applications.
Security permissions.
Windows Installer deployment requires administrative permissions and allows only limited user installation;
ClickOnce deployment enables non-administrative users to install and
grants only those Code Access Security permissions necessary for the
application.
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.