I am using the evaluation container image for Bluemix. I have downloaded the image, and configured all the .properties files for scripts. Then pushed the image. I have used Clouding as the DB.
When I start the container, I see no runtimes displayed in Operation Console. When I open Cloudant console, I can see only one DB created with the name of the project I chose to deploy. There is no DB for administration.
I am not able to check the logs, it throws an error when I chose to create a volume in startsrver script. I am not able to login using SSH as well although I pasted the SSH public key file in usr/ssh before pushing.
The standard flow to have all up running is this:
./installcontainercli.sh
./initenv.sh args/initenv.properties
./prepareserverdbs.sh args/prepareserverdbs.properties
#this step you will repeat for each runtime you have to install.
./prepareserverdbs.sh args/prepareserverdbs.InvokingAdapterProcedures.properties
#steps to be repeated for deploys
./prepareserver.sh args/prepareserver.properties
./startserver.sh args/startserver.properties
The tricky here is that in the args/prepareserverdbs.properties the runtime property is commented.
At the file args/prepareserverdbs.InvokingAdapterProcedures.properties is the same at the file args/prepareserverdbs.properties, it is not commented.
Said that first you run:
./prepareserverdbs.sh args/prepareserverdbs.properties
then you run the following command to to create the runtime DB:
./prepareserverdbs.sh args/prepareserverdbs.InvokingAdapterProcedures.properties
After that, you follow with the deploy sequence:
#steps to be repeated for deploys
./prepareserver.sh args/prepareserver.properties
./startserver.sh args/startserver.properties
Details at: https://developer.ibm.com/mobilefirstplatform/documentation/getting-started-7-1/bluemix/run-foundation-on-bluemix/
Example of the app properties:
# Licensed Materials - Property of IBM
# 5725-I43 (C) Copyright IBM Corp. 2011, 2013. All Rights Reserved.
# US Government Users Restricted Rights - Use, duplication or
# disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
################################################################################################################################################
# This file defines the various properties that needs to be provided for running the prepareserverdbs.sh script
# Run prepareserverdbs.sh script to configure the management and runtime databases for the MobileFirst Platform projects.
# The Bluemix DB service type. The value can be either sqldb or cloudantNoSQLDB
DB_TYPE=cloudantNoSQLDB
# Bluemix DB service instance name
DB_SRV_NAME=CloudantDB
# Bluemix database service plan to create the service instance. For SQL DB, the accepted values are sqldb_small, sqldb_free, sqldb_premium.
# For Cloudant DB, the accepted value is Shared
DB_SRV_PLAN=Shared
# Bluemix application name to bind the DB service instance
APP_NAME=<your app name>
# (Optional) The name of the runtime project to be deployed on MFPF server. Specified only for configuring runtime database
RUNTIME_NAME=FormBasedAuth
# (Optional) Database Schema Name. Defaults to WLADMIN for admin database and runtime name for runtime database
#SCHEMA_NAME=
Related
Is there a concise set of steps available to allow Tivoli Dynamic Workload Console (TDWC) v8.6 FP3 or v9.x to successfully create reports when the Tivoli Workload Scheduler (TWS) master is using Oracle as the database vendor?
TDWC v8.6 FP3 and v9.x do not include the JDBC libraries that allow a Type 4 connection to an Oracle database. Here is a typical message returned when attempting to connect to an engine in DWC when the "Enable reporting" box is checked, but the configuration work has not been done:
Manage Engines AWSUI0803W Test connection to "ENGINENAME" : engine successful, database failed. AWSUI0346E Database failure. Check the database is available and the connection parameters are correct and retry:
database user: TWS_user, database JDBC URL:jdbc:oracle:thin:#//1.2.3.4:1521/DBNAME If the problem persists contact the Tivoli Workload Scheduler administrator. The database internal message is: No suitable driver found for jdbc:oracle:thin#//1.2.3.4:1621/DBNAME
The TWS online documentation includes the procedure to accomplish the needed configuration. There are, however, a couple of external links that must be used to make the modifications within WebSphere Application Server (WAS). The full details are described below:
Actions taken on Tivoli Workload Scheduler engine:
For Oracle, the IT administrator, or the Tivoli Workload Scheduler IT administrator, or both working together, perform the following steps:
Use the TWS Oracle user specified during the master domain manager installation or perform the following steps to create a new user:
a. Create a database user authorized to access the database and specify a password.
b. Launch the following script: /TWS/dbtools/Oracle/scripts/dbgrant.bat/.sh
where the variables are as follows:
The Tivoli Workload Automation instance directory
The ID of the user created in step 1.a, who is going to be granted the access to the reports
The name of the database, as created when the master domain manager was installed
The user ID and password of the database schema owner.
Define a valid connection string to the database:
a. Ensure that the following property is set in the TWSConfig.properties file to point to the Oracle JDBC URL: com.ibm.tws.webui.oracleJdbcURL
FP3: /eWAS/profiles/TIPProfile/properties/TWSConfig.properties 9.x: /WAS/TWSProfile/properties/TWSConfig.properties
For example:
com.ibm.tws.webui.oracleJdbcURL= jdbc:oracle:thin:#//9.132.235.7:1521/orcl
b. Restart the WebSphere Application Server.
Actions taken on the Dynamic Workload Console:
Download the JDBC drivers required by your Oracle server version.
Copy the JDBC drivers into a directory that is accessible by the WebSphere Application Server used by your Dynamic Workload Console.
Create a shared library on WebSphere Application Server specifying the path and filename of the JDBC drivers you have copied, as documented below:
a. Login to the WebSphere Admin Console for TDWC as the WebSphere Administrative user.
v8.6 FP3: The default https admin port is 31124.
v9.x: The default https admin port is 16316.
The URL will be similar to this: https://(hostname):16316/ibm/console
b. Select Environment > Shared libraries in the console navigation tree.
c. Select the following scope from the dropdown list:
v8.6 FP3: Node=TIPNode01, Server=server1
v9.x: Node=JazzSMNode01, Server=server1
...and select [New]
d. Specify a new name such as oraclelibs
e. Specify the path to the directory that holds the Oracle JDBC drivers in the Classpath field.
*Field Detail: If a path in the list is a file, the product searches the contents of that Java archive (JAR) or compressed .zip file. If a path in the list is a directory, then the product searches the contents of JAR and compressed files in that directory. Press Enter to separate class path entries.
f. Select [Apply]
*NOTE: The file that is updated by the above step is: libraries.xml
v8.6 FP3: /eWAS/profiles/TIPProfile/config/cells/TIPCell/nodes/TIPNode/servers/server1/libraries.xml
v9.x: cells/JazzSMNode01Cell/nodes/JazzSMNode01/servers/server1/libraries.xml
Associate the isc Enterprise Application to this shared library:
a. Still in the WebSphere Admin Console, in the console navigation tree to access the Shared library references page: Select Applications > Application Types > WebSphere enterprise applications > isc > Shared library references
b. Check the box for the application named isc. This should be the first box and the only box under the section in the table with the second column named "Application".
c. Select the [Reference shared libraries] button.
d. In the "Available" box select the name of the new shared library that you created in step 3. For example: oraclelibs. Then select the Add arrow button to move the shared library name from the Available to Selected box.
e. Select [Ok]
f. Select [Ok] on the "Shared library references" page.
g. Select the blue word Save at the top of the page in the Messages box.
*NOTE: The files that are noted as being updated in this scenario are:
v8.6 FP3: cells/TIPCell/nodes/TIPNode/serverindex.xml cells/TIPCell/applications/isc.ear/deltas/isc/delta-<#> cells/TIPCell/applications/isc.ear/deployments/isc/deployment.xml
v9.x: cells/JazzSMNode01Cell/nodes/JazzSMNode01/serverindex.xml cells/JazzSMNode01Cell/applications/isc.ear/deltas/isc/delta-<#> cells/JazzSMNode01Cell/applications/isc.ear/deployments/isc/deployment.xml
**NOTE: It is the file deployment.xml that has reference to the actual shared library name that was created in step 3.
***NOTE: Sample entry:
h. Restart the WebSphere Application Server.
Log on to the Dynamic Workload Console.
In Dashboard Application Services Hub navigation bar, select System Configuration > Manage Engines. The Manage Engines panels opens.
Select the engine you defined or create another engine. The Engine Connection properties panel is displayed.
In Database Configuration for Reporting, perform the following:
a. Check Enable Reporting to enable the engine connection you selected to run reports.
b. In Database User ID and Password, specify the database user and password that you authorized to access reports.
I am trying to deploy the MobileFirst Admin Operational console using Server Configuration Tool. Started the configuration tool as root user. Create a configuration and saved the xml. Pressed the "Deploy" button. Its failed with JVM terminated Exit code -1 error.
MobileFirst Server Version 7.1.0.0-MFPF-Server-IF201510051721
WebSphere 8.5.5.7
Installation Manager JRE:jre_7.0.7001.20140909_1712
After this error, I am able to see the Admin console application and admin services application in WebSphere. But in Configuration Tool not able to create / add runtime under this configuration. It says no configuration found.
After this error, I am able to see the Admin console application and admin services application in WebSphere. But in Configuration Tool not able to create / add runtime under this configuration. It says no configuration found.
This is not a solution to the JVM crash you experiment, but a workaround to enable to be able to add the runtime (I understand from the above description that the crash happens after the Server Configuration Tool saved the configuration and deployed it).
Go to (homeDir)/.mobilefirst_platform_server/server-configuration-tool. You should find a directory named after your configuration. In that directory, you should find a file named (ConfigName).xml. Copy this file as (ConfigName).lastdeployed (ie same name as the xml file but change the suffix). The Server Configuration Tool would have created this file after deployment completion (and uses it for later operations such as uninstall) and it uses it as an indicator that the configuration is deployed.
I have a very small test application in which I'm trying to install a Windows Service and create a LocalDB database during the install process, then connect to that LocalDB database when the Windows Service runs.
I am running into huge problems connecting to a LocalDB instance from my Windows Service.
My installation process is exactly like this:
Execute an installer .msi file which runs the msiexec process as the NT AUTHORITY\SYSTEM account.
Run a custom action to execute SqlLocalDB.exe with the following commands:
sqllocaldb.exe create MYINSTANCE
sqllocaldb.exe share MYINSTANCE MYINSTANCESHARE
sqllocaldb.exe start MYINSTANCE
Run a custom C# action using ADO.NET (System.Data.SqlConnection) to perform the following actions:
Connect to the following connection string, Data Source=(localdb)\MYINSTANCE; Integrated Security=true
CREATE DATABASE TestDB
USE TestDB
CREATE TABLE ...
Start the Windows Service before the installer finishes.
The Windows Service is installed to the LocalSystem account and so also runs as the NT AUTHORITY\SYSTEM user account.
The service attempts to connect using the same connection string used above.
I am consistently getting the following error when trying to open the connection to the above connection string from within the Windows Service:
System.Data.SqlClient.SqlException (0x80131904): A network-related or
instance-specific error occurred while establishing a connection to
SQL Server. The server was not found or was not accessible. Verify
that the instance name is correct and that SQL Server is configured to
allow remote connections. (provider: SQL Network Interfaces, error: 50
- Local Database Runtime error occurred. The specified LocalDB instance does not exist.
This is frustrating because both the msi installer custom action and the Windows Service are running under the same Windows user account (I checked, they're both NT AUTHORITY\System). So why the first works and the second does not is beyond me.
I have tried changing the connection strings used in the custom action and the Windows Service to use the share name (localdb)\.\MYINSTANCESHARE and I get the exact same error from the Windows Service.
I have tried changing the user account that the Windows Service logs on as to my Windows user account, which does work as long as I first run a command to add it to the SQL server logins for that instance.
I've also tried running a console application and connecting to the share name connection string and that works as well.
I've also tried connecting to the share name from SQL Server Management Studio and that works as well.
However none of these methods really solve my problem. I need a Windows Service because it starts up as soon as the computer starts up (even if no user logs on) and starts up no matter which user account is logged in.
How does a Windows Service connect to a LocalDB private instance?
I am using SQL Server 2014 Express LocalDB.
Picking up from the comments on the question, here are some areas to look at. Some of these have already been answered in those comments, but I am documenting here for others in case the info might be helpful.
Check here for a great source of info on SQL Server Express LocalDB:
SQL Server 2014 Express LocalDB
SqlClient Support for LocalDB
SqlLocalDB Utlity
Introducing LocalDB, an improved SQL Express (also look at the Q&A section at the end of the main post, just before the comments, as someone asked if LocalDB can be launched from a service, and the answer is:
LocalDB can be launched from a service, as long as the profile is loaded for the service account.
What version of .Net is being used? Here it is 4.5.1 (good) but earlier versions could not handle the preferred connection string (i.e. #"(localdb)\InstanceName"). The following quote is taken from the link noted above:
If your application uses a version of .NET before 4.0.2 you must connect directly to the named pipe of the LocalDB.
And according to the MSDN page for SqlConnection.ConnectionString:
Beginning in .NET Framework 4.5, you can also connect to a LocalDB database as follows:
server=(localdb)\\myInstance
Paths:
Instances: C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Databases:
Created via SSMS or direct connection: C:\Users{Windows Login}\Documents or C:\Users{Windows Login}
Created via Visual Studio: C:\Users{Windows Login}\AppData\Local\Microsoft\VisualStudio\SSDT
Initial Problem
Symptoms:
Database files (.mdf and .ldf) created in the expected location:
C:\Windows\System32\config\systemprofile
Instance files created in an unexpected location:
C:\Users\{current user}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
Cause (note taken from "SqlLocalDB Utility" MSDN page that is linked above; emphasis mine):
Operations other than start can only be performed on an instance belonging to currently logged in user.
Things to try:
Connection string that specifies the database (though maybe a long-shot if the error is regarding not being able to connect to the instance):
"Server=(LocalDB)\MYINSTANCE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
"Server=(LocalDB)\.\MYINSTANCESHARE; Integrated Security=true ;AttachDbFileName=C:\Windows\System32\config\systemprofile\TestDB.mdf"
Is the service running? Run the following from a Command Prompt:
TASKLIST /FI "IMAGENAME eq sqlservr.exe"
It should probably be listed under "Console" for the "Session Name" column
Run the following from a Command Prompt:
sqllocaldb.exe info MYINSTANCE
And verify that the value for "Owner" is correct. Is the value for "Shared name" what it should be? If not, the documentation states:
Only an administrator on the computer can create a shared instance of LocalDB
As part of the setup, add the NT AUTHORITY\System account as a Login to the system, which is required if this account is not showing as the "Owner" of the instance:
CREATE LOGIN [NT AUTHORITY\System] FROM WINDOWS;
ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT AUTHORITY\System];
Check the following file for clues / details:
C:\Users{Windows Login}\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MYINSTANCE\error.log
In the end you might need to create an actual account to create and own the Instance and Database, as well as run your service. LocalDB really is meant to be user-mode, and is there any downside to having your service have its own login? And you probably wouldn't need to share the instance at that point.
And in fact, as noted by Microsoft on the SQL Server YYYY Express LocalDB MSDN page:
An instance of LocalDB owned by the built-in accounts such as NT AUTHORITY\SYSTEM can have manageability issues due to windows file system redirection; Instead use a normal windows account as the owner.
UPDATE (2015-08-21)
Based on feedback from the O.P. that using a regular User account can be problematic in certain environments, AND keeping in mind the original issue of the LocalDB instance being created in the %LOCALAPPDATA% folder for the user running the installer (and not the %LOCALAPPDATA% folder for NT AUTHORITY\System ), I found a solution that seems to keep with the intent of easy installation (no user to create) and should not require needing extra code to load the SYSTEM profile.
Try using one of the two built-in accounts that is not the LocalSystem account (which does not maintain its own registry info. Use either:
NT AUTHORITY\LocalService
NT AUTHORITY\NetworkService
Both have their profile folders in: C:\Windows\ServiceProfiles
While I have not been able to test via an installer, I did test a service logging on as NT AUTHORITY\NetworkService by setting my SQL Server Express 2014 instance to log on as this account, and restarted the SQL Server service. I then ran the following:
EXEC xp_cmdshell 'sqllocaldb c MyTestInstance -s';
and it created the instance in: C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
I then ran the following:
EXEC xp_cmdshell N'SQLCMD -S (localdb)\MyTestInstance -E -Q "CREATE DATABASE [MyTestDB];"';
and it had created the database in: C:\Windows\ServiceProfiles\NetworkService
I was able to solve similar issue in our WiX installer recently. We have a Windows service, running under SYSTEM account, and an installer, where LocalDB-based storage is one of the options for database configuration. For some time (a couple of years actually) product upgrades and service worked quite fine, with no issues related to LocalDB. We are using default v11.0 instance, which is created in SYSTEM profile in C:\Windows\System32\config tree, and a database specified via AttachDbFileName, created in ALLUSERSPROFILE tree. DB provider is configured to use Windows authentication. We also have a custom action in installer, scheduled as deferred/non-impersonate, which runs DB schema updates.
All this worked fine until recently. After another bunch of DB updates, our new release started to fail after having upgraded over the former - service was unable to start, reporting infamous "A network-related or instance-specific error occurred while establishing a connection to SQL Server" (error 50) fault.
When investigating this issue, it became apparent that the problem is in a way WiX runs custom actions. Although non-impersonated CA-s run under SYSTEM account, the registry profile and environment remain that of current user (I suspect WiX loads these voluntary when attaching to user's session). This leads to incorrect path being expanded from the LOCALAPPDATA variable - the service receives SYSTEM profile one, but the schema update CA works with the user's one.
So here are two possible solutions. The first one is simple, but too intrusive to user's system - with cmd.exe started via psexec, recreate broken instance under the SYSTEM account. This was not an option for us as the user may have other databases created in v11.0 instance, which is public. The second option assumed lots of refactoring, but wouldn't hurt anything. Here is what to do to run DB schema updates properly with LocalDB in WiX CA:
Configure your CA as deferred/non-impersonate (should run under SYSTEM account);
Fix environment to point to SYSTEM profile paths:
var systemRoot = Environment.GetEnvironmentVariable("SystemRoot");
Environment.SetEnvironmentVariable("USERPROFILE", String.Format(#"{0}\System32\config\systemprofile", systemRoot));
Environment.SetEnvironmentVariable("APPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Roaming", systemRoot));
Environment.SetEnvironmentVariable("LOCALAPPDATA", String.Format(#"{0}\System32\config\systemprofile\AppData\Local", systemRoot));
Environment.SetEnvironmentVariable("HOMEPATH", String.Empty);
Environment.SetEnvironmentVariable("USERNAME", Environment.UserName);
Load SYSTEM account profile. I used LogonUser/LoadUserProfile native API methods, as following:
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
[return: MarshalAs(UnmanagedType.Bool)]
private static extern bool LogonUser(
string lpszUserName,
string lpszDomain,
string lpszPassword,
int dwLogonType,
int dwLogonProvider,
ref IntPtr phToken);
[StructLayout(LayoutKind.Sequential)]
struct PROFILEINFO
{
public int dwSize;
public int dwFlags;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpUserName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpProfilePath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpDefaultPath;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpServerName;
[MarshalAs(UnmanagedType.LPWStr)]
public String lpPolicyPath;
public IntPtr hProfile;
}
[DllImport("userenv.dll", SetLastError = true, CharSet = CharSet.Unicode)]
[return: MarshalAs(UnmanagedType.Bool)]
static extern bool LoadUserProfile(IntPtr hToken, ref PROFILEINFO lpProfileInfo);
var hToken = IntPtr.Zero;
var hProfile = IntPtr.Zero;
bool result = LogonUser("SYSTEM", "NT AUTHORITY", String.Empty, 3 /* LOGON32_LOGON_SERVICE */, 0 /* LOGON32_PROVIDER_DEFAULT */, ref token);
if (result)
{
var profileInfo = new PROFILEINFO();
profileInfo.dwSize = Marshal.SizeOf(profileInfo);
profileInfo.lpUserName = #"NT AUTHORITY\SYSTEM";
if (LoadUserProfile(token, ref profileInfo))
hProfile = profileInfo.hProfile;
}
Wrap this in an IDisposable class, and use with a using statement to build a context.
The most important - refactor your code to perform necessary DB updates in a child process. This could be a simple exe-wrapper over your installer DLL, or stand-alone utility, if your already have one.
P.S. All these difficulties could be avoided, if only Microsoft let uses choose where to create LocalDB instances, via command line option. Like Postgres' initdb/pg_ctl utilities have, for example.
I suggest using a different user account, and not using the System account, by doing the following:-
create a new account on the machine, and set that to be the account
under which the Windows Service runs. It's not good practice to use
the system account just to run an application, anyway, as the
permissions are excessive.
ensure that the permissions on the LocalDB files are set to allow the said user account to access the database (and thus continue to
use Integrated Security)
make sure it works by trying to connect to the DB (once installed) under the same user account by running sqlcmd or Management Studio
under the context of the said user, then connecting with Integrated
Security to ensure it works.
Some other things to try/consider:
have you checked the Windows Event log for any events that might be useful for diagnostic purposes?
Make sure that if you have any other versions of SQL Server (especially prior to 2012) that for the command-line tools, the %PATH% isn't set to find an older tools version first. Older tools don't support LocalDB.
It is possible also (as an alternative) to set up LocalDB to be shared with other users. This involves sharing the instance, and then granting access to other users. See the "Sharing Issues" section in this article: Troubleshoot SQL Server 2012 Express LocalDB.
There's also another SO article that may contain some more useful information there in the links within (change the language in the URL from Polish to English by changing pl-pl to en-us). His work-around is using SQL Server accounts, which might not be OK in your case.
This might also be useful, as it relates to security permissions being denied, and possible resolutions: https://dba.stackexchange.com/questions/30383/cannot-start-sqllocaldb-instance-with-my-windows-account
Trevor, the problem you have is with the MSI custom actions. You must configure them with "Impersonate=false" otherwise the custom actions will be executed under the current user context.
BTW what tool are you using to create the installer?
Depending on the tool you use, could you please provide screenshots or code snippets of your custom actions configuration?
The accepted answer from this post will give you some additional information about the different custom action execution alternatives:
Run ExeCommand in customAction as Administrator mode in Wix Installer
You will find additional information about impersonation here:
http://blogs.msdn.com/b/rflaming/archive/2006/09/23/768248.aspx
I wouldn't create the database under the system's localdb instance. I'd create it under the current user installing the product. This will make life much easier if you need to delete or manage the database. They can do this through sql management studio. Otherwise, you'll have to use psexc or something else to launch a process under the SYSTEM account to manage it.
Once the db is created, then use the share option you mentioned. The SYSTEM account can then access the database through the share name.
sqllocaldb share MSSqlLocalDb LOCAL_DB
When sharing, I've noticed you'll have to restart the the local db instance to actually access the db through the share name:
sqllocaldb stop MSSQLLocalDB
sqllocaldb start MSSQLLocalDB
Also, You may need to add the SYSTEM account as a db reader and writer to the database ...
EXEC sp_addrolemember db_datareader, 'NT AUTHORITY\SYSTEM'
I have created a configuration.ini file so I can do a quiet install of SQL 2012 Express. I installed the full version far enough to get the configuration file.
Every time I run my batch file that calls the config file I get the following error at the end of my Detail.txt
(01) 2014-03-07 13:21:42 Slp: Setup result: 0
(01) 2014-03-07 13:21:42 Slp: SQM Service: Sqm does not have active session.
I am using a new PC with Windows 8 and Visual Studio 2010 installed.
This is my configuration file - can anyone see what I am missing.
(01) 2014-03-07 13:21:42 Slp: Setup result: 0 (01) 2014-03-07 13:21:42
Slp: SQM Service: Sqm does not have active session.
;SQL Server 2012 Configuration File [OPTIONS]
; Specifies a Setup work flow, like INSTALL, UNINSTALL, or UPGRADE.
This is a required parameter.
ACTION="Install"
; Detailed help for command line argument ENU has not been defined
yet.
ENU="True"
; Parameter that controls the user interface behavior. Valid values
are Normal for the full UI,AutoAdvance for a simplied UI, and
EnableUIOnServerCore for bypassing Server Core setup GUI block.
; Setup will not display any user interface.
QUIET="True"
; Setup will display progress only, without any user interaction.
QUIETSIMPLE="False"
; Specify whether SQL Server Setup should discover and include product
updates. The valid values are True and False or 1 and 0. By default
SQL Server Setup will include updates that are found.
UpdateEnabled="True"
; Specifies features to install, uninstall, or upgrade. The list of
top-level features include SQL, AS, RS, IS, MDS, and Tools. The SQL
feature will install the Database Engine, Replication, Full-Text, and
Data Quality Services (DQS) server. The Tools feature will install
Management Tools, Books online components, SQL Server Data Tools, and
other shared components.
FEATURES=SQLENGINE,REPLICATION,FULLTEXT,RS,BIDS,CONN,BC,SDK,BOL,SSMS,ADV_SSMS,SNAC_SDK,LOCALDB
; Specify the location where SQL Server Setup will obtain product
updates. The valid values are "MU" to search Microsoft Update, a valid
folder path, a relative path such as .\MyUpdates or a UNC share. By
default SQL Server Setup will search Microsoft Update or a Windows
Update service through the Window Server Update Services.
UpdateSource="MU"
; Displays the command line parameters usage
HELP="False"
; Specifies that the detailed Setup log should be piped to the
console.
INDICATEPROGRESS="False"
; Specifies that Setup should install into WOW64. This command line
argument is not supported on an IA64 or a 32-bit system.
X86="False"
; Specify the root installation directory for shared components. This
directory remains unchanged after shared components are already
installed.
; INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server"
; Specify the root installation directory for the WOW64 shared
components. This directory remains unchanged after WOW64 shared
components are already installed.
; INSTALLSHAREDWOWDIR="C:\Program Files (x86)\Microsoft SQL Server"
; Specify a default or named instance. MSSQLSERVER is the default
instance for non-Express editions and SQLExpress for Express editions.
This parameter is required when installing the SQL Server Database
Engine (SQL), Analysis Services (AS), or Reporting Services (RS).
INSTANCENAME="MyInstance_12" SAPWD="MyPasswordr3r443r43r3$$" ; Specify
the Instance ID for the SQL Server features you have specified. SQL
Server directory structure, registry structure, and service names will
incorporate the instance ID of the SQL Server instance.
INSTANCEID="INTEGRATED_3D_12"
; Specify that SQL Server feature usage data can be collected and sent
to Microsoft. Specify 1 or True to enable and 0 or False to disable
this feature.
SQMREPORTING="False"
; RSInputSettings_RSInstallMode_Description
RSINSTALLMODE="DefaultNativeMode"
; Specify if errors can be reported to Microsoft to improve future SQL
Server releases. Specify 1 or True to enable and 0 or False to disable
this feature.
ERRORREPORTING="False"
; Specify the installation directory.
INSTANCEDIR="C:\Program Files\Microsoft SQL Server"
; Agent account name
AGTSVCACCOUNT="NT AUTHORITY\NETWORK SERVICE"
; Auto-start service after installation.
AGTSVCSTARTUPTYPE="Disabled"
; CM brick TCP communication port
COMMFABRICPORT="0"
; How matrix will use private networks
COMMFABRICNETWORKLEVEL="0"
; How inter brick communication will be protected
COMMFABRICENCRYPTION="0"
; TCP port used by the CM brick
MATRIXCMBRICKCOMMPORT="0"
; Startup type for the SQL Server service.
SQLSVCSTARTUPTYPE="Automatic"
; Level to enable FILESTREAM feature at (0, 1, 2 or 3).
FILESTREAMLEVEL="0"
; Set to "1" to enable RANU for SQL Server Express.
ENABLERANU="True"
; Specifies a Windows collation or an SQL collation to use for the
Database Engine.
SQLCOLLATION="Latin1_General_CI_AS"
; Account for SQL Server service: Domain\User or system account.
SQLSVCACCOUNT="NT Service\MSSQL$INTEGRATED_3D_12"
; Windows account(s) to provision as SQL Server system administrators.
; The default is Windows Authentication. Use "SQL" for Mixed Mode
Authentication.
SECURITYMODE="SQL"
; Provision current user as a Database Engine system administrator for
SQL Server 2012 Express.
ADDCURRENTUSERASSQLADMIN="True"
; Specify 0 to disable or 1 to enable the TCP/IP protocol.
TCPENABLED="0"
; Specify 0 to disable or 1 to enable the Named Pipes protocol.
NPENABLED="0"
; Startup type for Browser Service.
BROWSERSVCSTARTUPTYPE="Automatic"
; Specifies which account the report server NT service should execute
under. When omitted or when the value is empty string, the default
built-in account for the current operating system. ; The username part
of RSSVCACCOUNT is a maximum of 20 characters long and ; The domain
part of RSSVCACCOUNT is a maximum of 254 characters long.
RSSVCACCOUNT="NT Service\ReportServer$INTEGRATED_3D_12"
; Specifies how the startup mode of the report server NT service.
When ; Manual - Service startup is manual mode (default). ; Automatic
- Service startup is automatic mode. ; Disabled - Service is disabled
RSSVCSTARTUPTYPE="Automatic"
; Add description of input argument FTSVCACCOUNT
FTSVCACCOUNT="NT Service\MSSQLFDLauncher$INTEGRATED_3D_12"
IACCEPTSQLSERVERLICENSETERMS="True"
Mainly looking to answer my question #1 below, but more knowledge would be appreciated.
I tried to use these resources during my investigation, but was unsuccessful:
http://social.msdn.microsoft.com/Forums/en/sqldatabaseengine/thread/f5eb164d-9774-4864-ae05-cac99740949b (For this error: Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed.)
http://social.msdn.microsoft.com/forums/en-US/sqlexpress/thread/6dfdcc22-7a81-4e8f-a947-c1ce6982d4b3/ (For this error: CREATE DATABASE permission denied in database master. An attempt to attach an auto-named database for file ? failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.)
Questions
1.) Why does this error occur while running the Telerik Rad Controls for ASP.NET AJAX "Live Demos" project with IIS 7 (Running Telerik Live Demos works fine using ASP.NET Development Server with this connection string)
Failed to generate a user instance of SQL Server due to failure in retrieving the user's local application data path. Please make sure the user has a local user profile on the computer. The connection will be closed.
2.) How is creating a SQL Server Express instances different in IIS 7, from ASP.NET Development Server & SSMSE
3.) Are there certain attributes of a SQL connection string not allowed when running a website on different contexts (based on #2).
Environment:
I'm not running the "Live Demos" .NET 3.5 ASP.NET web application via the ASP.NET Development Server (feature that pops up in your system tray and picks a port for you after clicking play in Visual Studio). That works just fine! I'm running the website on IIS 7. SQL Server Express is using the NETWORK SERVICE user in Control Panel > Administrative Tools > Services > SQL Server (SQLExpress).
Using this connection string provided with the installed "Live Demos" web application demo project:
<add name="NorthwindConnectionString"
connectionString="Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|Northwind.mdf;Integrated Security=True;User Instance=True"
providerName="System.Data.SqlClient" />
I've tried setting "User Instance=False", but that just throws another error:
CREATE DATABASE permission denied in database master. An attempt to attach an auto-named database for file ? failed. A database with the same name exists, or specified file cannot be opened, or it is located on UNC share.
(where "?" is the path of the *.mdf file - C:\Users\\MyDocuments\Visual Studio 2008\Projects\TelerikDemos\Telerik\RadControls for ASP.NET AJAX Q2 2011\Live Demos\App_Data\Northwind.mdf .. Stack Overflow italics is broken with some of those characters, so I had to remove that path)
Someone answered me on a previous question to set this "User Instance=False", but it appears User instances have nothing to do with whether or not you use SQL Express. User Instances are simply a feature of SQL Express that allows a very unprivileged user to host a database instance in it's own user context.
Note, this Northwind database is stored in an *.mdf file in the App_Data folder (under the "Live Demos" root application directory) along with the *.ldf (log file). I did previously try attaching the *.mdf files as actual databases under the "Databases" folder (in the SSMSE Object Explorer tree), but later removed them.
Web application "Live Demos" root folder (and nested folders/files) have the following users assigned with ALL privileges:
- IIS APPPOOL\Telerik ("Telerik" is the name of my application pool in IIS 7 for this site)
- IUSR
- NETWORK SERVICE
Making a note for myself about this SQLExpress master database query:
SELECT * FROM sys.dm_os_child_instances
Also tried different combinations of *.mdf & *.ldf permissions while also changing the user on the SQL Server (SQLExpress) Windows 7 service (Control Panel > Administrative Tools > Services) .. and also restarted the service after making those changes.
To reproduce:
download the Telerik Rad Controls for ASP.NET AJAX. Set the permimssions I mentioned in the "Live Demos" folder under Program Files\Telerik, change the .NET version of the web application to .NET 3.5, switch out their 3.5 web.config file with the normal web.config file in that folder. You have to use Visual Studio 2010, but I am running this in Visual Studio 2008 (with a little grunt work I did because our company is not yet on VS2010). Also switch out the proper Bin35 assemblies into the "Live Demos" folder Bin folder. Compile the solution. Create an IIS 7 website. Add Windows authentication. Enabled anonymous and Windows authentication.. all others are disabled. Set application pool to use Classic and 32 bit.
Then navigating to this URL and clicking the "First Look" image.
http://localhost/combobox/examples/overview/defaultcs.aspx
====================
More evidence will be provided if requested.
You are using a connection string with trusted authentication = true. This means that the connection uses the security context of the calling process.
When you run with the development server you are running in the security context of the logged in user, so every thing works fine.
When you run in IIS you are in the security context of the application pool process, which is NETWORK SERVICE, which does not have a user profile, therefore it crashes.
You can fix it by either:
Change the identity of the application pool to a normal user with access to the database
Use a connection string with user name and password
IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the Network Service account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new application pool.
However, if you want, you can configure IIS application pools to load the user profile by setting the LoadUserProfile attribute to "true".
https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities