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
Related
Building a tabular model in Visual Studio I'm facing an issue when trying to deploy the model to the Analysis Service Server (SQL Server 2019 Standard). I get this error:
Cannot deploy metadata. Reason: An error occurred while connecting to the server.
I already set the deployment server in the model properties. And the last thing I tried was to set the Administrator local user of the SQL Server in the Impersonation Information dialog, but is giving me the invalid user / password error.
Also tried to use Service Account, but having the same error.
I can get the data from the SQL Server (using SQL Server Authentication) but the problem is when trying to deploy the model to the Analysis Server.
Is this error caused because the servers are not part of an AD?
Any way to work around this, or way to see any logs?
Using Visual Studio 2017 and 2019.
Thanks.
Is this error caused because the servers are not part of an AD?
Possibly. SSAS only supports Windows Integrated Auth, so you need to make that work. The preferred method is to deploy from a session owned by a SSAS administrator, from a workstation in the same domain.
If that's not possible there are a couple of other options. One is to create a local account on both the workstation and the server with the same name and password, and log in as that account to deploy.
The other is to install a Windows Credential in the windows credential store for an identity that has rights to deploy to the SSAS database. Or to run visual studio via runas /netonly specifying the credentials for the remote server.
I am trying to find a solution to three issues I have encountered recently relating to SQL Server 2014. I am not an expert with this stuff by any means, but I've sort of fallen into needing to learn it in my current role. I went from never using SSMS a few months ago to (Trying) to teach myself how to use SSIS and SSRS. I've made a ton of progress, but now I'm stuck actually getting everything automated the way I want it.
The biggest challenge, and root of all my problems, stems from the fact that I am not a local admin on my machine. It was great to finally get IT to install the programs, but they do not want to give me, or anyone not in IT in my company, local admin access. Apart from asking my director to try to convince them to do so, I'm hoping for some solutions that would mean I don't have to call them every day to run these programs.
My integration server is running, I've got my SSIS packages built, but I can't connect to the Integration Server through SSMS, as I am not a local admin on my machine. I've read about going through dcomcnfg settings for REMOTE access issues, but I'm worried that won't help here since I'm trying to do this from the local machine and it still doesn't work. Any ideas as to how I can change the settings so that it runs for non-admin accounts or just make it work?
SSRS: I've built a report, and want to deploy it, but I don't have access to the reporting services configuration manager either. For whatever reason my reporting server is stopped in the server configuration manager. When I click on it, it says to use reporting services config mgr to tweak settings, so a bit stuck. Appears to be the same issue - not a local admin. Again, are there any settings I can change (getting IT to log in as an admin and walking them through what to change is my only choice, essentially).
SQL Server agent appears to be the same issue...
I could probably run my reports now, but it would be so much nicer to use these programs to the full extent. Any help would be appreciated here. I tried to research as much as possible, but most solutions seem to relate to logging on myself as an admin, running things as admin, etc, and I just can't do that.
Thanks!
You do not need to be local admin on your machine, SSIS and SSAS require Windows Authentication to log on remotely to the server via SSMS and publishing anything to the server from BIDS / SSDT Visual Studio Shell also requires WinAuth, though you can work locally and then swap the package to the server via Ctrl-C, and also instead of deploying SSRS you can login directly to the report manager and upload an RDL file (report). To start and stop SQL Agent services you need Windows Authentication via SSMS (in your setup), but to view the SQL Agent you must be in the SQL Server SysAdmin role (or at a grain level SQL Agent Reader via the MSDB rights.
I recommend you attempt to not get local administrator rights and instead ask 'merely' for rights to read and write to the server drives, and to manage only the aspects of SQL Server and it's services with a domain login on the server. You will require this anyway to check ingress and egress file locations and debug production issues (unless you have FTP to the box).
You do not have access to stop or start SQL Agent from your client SSMS also because I believe you are accessing it via SQL Authentication, which is not ideal or secure. But if you do not see the agent on the bottom left of SSMS it is because you do not have rights. If you see the Agent and it is red then the service is disabled and must be started.
You will need to get direct access to the SQL box (and you do not need local admin to manage SQL Server, just a domain account with some service rights and drive rights). If your system administrators are running SQL Server under Local Admin, then they should not be managing SQL Server in the first place (see my write up hyperlinked below).
The SSRS Team at Microsoft has merged into the SharePoint team, and SharePoint 2013 wraps up all of the BI tools right into it, so that is something you should also consider if you plan on building out a BI shop at your firm, i.e. you may not have to if you already have SharePoint installed.
Good luck, don't get discouraged.
What user account would you recommend running the SQL Server Express 2008 services in a development environment?
Here is what happened. I run a web application on windows server 2008 R2. The app pool it uses runs under LocalSystem account. The application complained about "NT Authority\SYSTEM" not having access to my database, so i added that user to the database. It all worked fine until yesterday, when the application started complaining about "Development\MyMachineName$" not having access to my database. The app pool still is running under "LocalSystem" account. I am confused why is it now changed the identity.
While playing around i ended up removing my username from sql server security. My sql server 2012 instance is running in windows authentication mode. now i cant connect to the sql instance. to fix this found someone suggested to use "psexec -i -s ssms" to launch management studio under "NT Authority\System" account. when i tried this the management studio tries to log on with "Development\MyMachineName$" as well. i am now wondering what happened to "NT Authority\SYSTEM" identity.
Thanks in advance for the upcoming help :)
EDIT:
My SQL Server instance is on same machine as the web application. i.e. its a dev machine where is have iis and sql server running for development.
Lots of stuff going on here, so hopefully this will clarify things for you.
I run a web application on windows server 2008 R2. The app pool it
uses runs under LocalSystem account. The application complained about
"NT Authority\SYSTEM" not having access to my database, so i added
that user to the database.
If the database server is local to the IIS server, that's fine (though I would still use a domain account to run the app pool). If the database server is remote from the IIS Server then the "local system" pool with attempt to authenticate a network resource which will transition to using the computer account Domain\Computer$ (as would network service).
It all worked fine until yesterday, when the application started
complaining about "Development\MyMachineName$" not having access to my
database. The app pool still is running under "LocalSystem" account.
I can't tell from your question if these are the same server or not, more clarification would be needed.
While playing around i ended up removing my username from sql server
security. My sql server 2012 instance is running in windows
authentication mode. now i cant connect to the sql instance. to fix
this found someone suggested to use "psexec -i -s ssms" to launch
management studio under "NT Authority\System" account. when i tried
this the management studio tries to log on with
"Development\MyMachineName$" as well. i am now wondering what happened
to "NT Authority\SYSTEM" identity.
NT Authority\System is a special built in identity and does not traverse network resources, if it needs to it auths as the computer account Domain\Computer$. I don't know the whole setup from your text but for the psexec to work, it'd have to start ssms on the database server or it will continue to use the computer account. If you need access back, be a member of the server admins windows group and start SQL Server up in single user mode - connect with windows authentication (locally) and add your login back in.
We'd need a infrastructure diagram to get more into it, but the basics are:
Built in identities and accounts can't authenticate on a network unless they use the computer object.
Built in identities and accounts are only good for the server they are on and local to.
Giving permissions to anyone who could access that computer (through the computer object) is grossly over-provisioning permissions.
If you are running an application, the identity if yours so you could have been authenticating with your account the whole time testing. While individual threads can have different identities, most applications inherit the identity that spawned the process and in this case is most likely yours.
I think i figured it out. The reason was that when connection string uses computer name then it forwards "MACHINE$" as identity but when it is using localhost then it forwards "SYSTEM" as identity.
I have created a SSIS Package and now want to deploy it, for that I am required to create the Integration Service Catalog,so I have SQL Server Evaluation Set up in that when I m trying to connect the integration service, I am getting following error,
Connecting to the Integration Services service on the computer
"RESHMAJADHAV"
failed with the following error: "Access is denied."
By default, only administrators have access to the Integration Services service.
On Windows Vista and later,
the process must be running with administrative privileges in
order to connect to the Integration Services service.
See the help topic for information on how to configure access to the service.
Also I have observed that my instance for SQL Server Evaluation edition is RESHMAJADHAV\SQL_SERVER_EVALU but when I am trying to connect this server, then this option is not shown under Integration Services as shown below,
.
I am unable to sort this out, since I am entirely new to this, please explain what can be the solution.
Please make a note, I also have sql server express edition ,but since it doesn't support to create the SSIS Integration service catalog then I installed the SQL Server Evaluation edition .
Also when I am trying to connect via SQL Database as shown in below image,
then while creating the integration service catalog, it is given the following error
Password validation failed.
The password doesn't meet the requirements of password of the password filter DLL.
Change database context to SSISDB.
One fact I have observed, I don't know whether it is related or not but when I am trying to enter password for my system, then also it's giving same error that password doesn't meet the requirement and also when while installing the SQL Server edition, it gave the same error, no doubt my password was very strong and fulfill all the requirements of strong password, currently I am trying to run my SQL Server with windows authentication mode and also I have tried to disable the strong password policies from the administrative tools but it's totally futile....any help will be greatly appreciated.
Go to all programs
Click on Microsoft SQL Server 2012 folder
Right click on SQL Server Management Studio
Click on Run as Administrator
This should take care of problem for now. (With this you need to always repeat the same process). To avoid this every time and for a more persistent solution you need to get permission(s). Please do the following process and you should be good.
In previous versions of SQL Server, by default when you installed SQL Server all users in the Users group had access to the Integration Services service. When you install the current release of SQL Server, users do not have access to the Integration Services service. The service is secure by default. After SQL Server is installed, the administrator must grant access to the service.
To grant access to the Integration Services service
Run Dcomcnfg.exe. Dcomcnfg.exe provides a user interface for modifying certain settings in the registry.
In the Component Services dialog, expand the Component Services > Computers > My Computer > DCOM Config node.
Right-click Microsoft SQL Server Integration Services 11.0, and then click Properties.
On the Security tab, click Edit in the Launch and Activation Permissions area.
Add users and assign appropriate permissions, and then click Ok.
Repeat steps 4 - 5 for Access Permissions.
Restart SQL Server Management Studio.
Restart the Integration Services Service.
(Source MSDN)
I hope this will help
I researched little bit and then I came to know it was actually the problem of HP Security Tool Manager service of HP Laptop which was messing with the password of system,SQL Setup and catalog of Integration Service,I uninstalled it from PC and now my problem is resolved..
look like you don't have a admin privilege.
so start->sql server->right click->run as administrator
it might solve !!!
it's not clear whether this is due to your windows password or the SSISDB encryption password http://fendy-huang.blogspot.com.au/2012/01/sql-server-2012-integration-services.html.
I suggest you think of a very long complicated password with a mixture of upper, lower and punctiation like this:
~~AgFcDeUk17aP9%3(5#hY,lTSs9+
and put that into the encryption field when creating the catalog. If that doesn't get around your error, try changing your windows password to that. The only way to solve thedr things is divide and conquer. Once you know which password is the issue you can attack it further.
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.