In order to help out one of our departments here I've cloned a machine that was on its last legs and is actually hosting some important data. The plan is to migrate to a VMware VM as soon as possible, but in the meantime I cloned the machine onto another PC for testing among other things.
I've renamed the original machine's hostname,
so the new machine is running ASP.NET and SQL Server 2005 (Express)
and the database-driven website (Intranet-only) is now back up and running but we're getting an error 4200 with ODBC about a login failed.
On checking the event viewer there's the following message:
However it seems that SQL server still sees the local accounts as being under a much older hostname (see below:)
If I try to add the user "CURRENTHOSTNAME\ASPNET" to the database in question it only sees the old hostname. Is this what's causing my problem ? I'm not sure.
I do know that to get IIS working in the first place I had to do "aspnet_reg.exe -ga CURRENTHOSTNAME\ASPNET" and that fixed my first problem but this second one has me stumped.
The third party company that supply the software are being very slow to help on this. I usually do PHP & MySQL so I've little to no knowledge of Microsoft SQL. If anybody can help me you'd really be saving my bacon as this is dragging on a couple of days now.
Thanks in advance!
Renaming a machine with a SQL server instance on it can be tricky. My guess is that you get the old machine name when you run this query:
SELECT ##SERVERNAME
If you do, the old computer name is still stored in the sys.servers table. You might be able to simply follow Microsoft's instructions at renaming, which is just running a couple of stored procedures:
sp_dropserver 'old_host_name'
GO
sp_addserver 'new_host_name', local
GO
By cloning a machine you're opening a big can of worms. My suggestion would be to backup data only and restore it to new computer with fresh installs of everything. But in your case, there are two things that I'd try:
after cloning you must reset SID - check this link
sql recognises users by their id/guid, so delete all users from sql server/database and add them from scratch
Okay it seems to be fixed now - I re-added the NEWHOSTNAME\ASPNET to Security\Logins under "Microsoft SQL Server Management Studio Express" and then it appeared under Databases\MyDatabase\Security\Users" or I was able to add it anyway (can't remember which) - not sure if renaming the server that shows up under SELECT ##SERVERNAME makes a difference, but this error is fixed now anyway
Related
We are using a Self-Hosted Integration Runtime for Azure Data Factory.
On that machine there was installed an Exasol ODBC driver of version 6. We wanted to upgrade the driver, deleted an old one and installed a new driver of version 7.
Weird thing is that now in Exasol logs we can see that Data Factory is sometimes connecting via driver version 7, and sometimes via driver version 6.
I made an experiment and deleted Exasol ODBC driver from the machine completely. After that Data Factory still was able to connect to Exasol using the driver I just deleted.
Looks like drivers' DLLs are cached somewhere. What can it be?
Update 1
I captured following actions in Process Monitor when Data Fatory connected to Exasol with ODBC driver of version 6:
Where these C:\Config.Msi\3739be5*.rbfASolution-6.1\ODBC\ DLLs may come from? There is no C:\Config.Msi\ directory on the machine.
Update 2
I noticed that when I test connection via Microsoft Integration Runtime Configuration Manager on the machine or in Data Factory Linked Service, then connection is always performed with ODBC driver of version 7.
But when I test connection via Data Factory Dataset, then in some cases connection is done with ODBC driver of version 6.
You could check the registry but clean at your own risk. An alternative might be the SysIternals tools, Process Monitor or Process Explorer which might help you get to the bottom of this. Install them on the SHIR VM if you are allowed to. Process Explorer in particular is a bit like SQL Profiler (if you've ever used that) so will be able to tell you which registry keys external processes are using. It will give you a lot a lot of information so you will have to make judicious use of timestamp and filtering. The proposed steps:
Start a trace using Process Monitor
Start a pipeline using the Exasol driver
Wait til it completes (or at least you know it has started)
Stop the Process Monitor trace Spend time going through the millions
of records it has captured, trying to filter down, or search for your
process
An alternative would be to build a clean SHIR and install only the new driver. Then swap it in for the old one. You may have to get the new SHIR added to the firewall if this is an issue for you.
Honestly I would propose both of these approached in parallel for a production problem. Procmon / Process Explorer can be quite labour and time expensive but should help you get to the bottom of the issue. Building a cleaner SHIR is probably a safer option in the long-term, but requires new infrastructure.
It may sound silly, but rebooting the server where SHIR is working solved the problem.
We noticed, that this server was running for more than 30 days, and decided to reboot it. Maybe restarting Integration Runtime service itself would also help, but we didn't do it.
Thanks to everyone for you help.
Can anyone tell me why I'm getting the following error when installing BizTalk 2013 R2 CU2:
BtsDeploySystemAssemblyTask has stopped working
I might have had this same problem recently and the solution was to run the update as a different user that had more permissions and it worked.
Since the error is coming up through the SqlClient, you need to make sure the running user has high level permissions to all the databases or even the entire SQL Server Instance.
Sorry :( but since it was a single event, we had no opportunity to repro or investigate though the successful user was a fully sysadmin on SQL Server and Domain Administrator.
I have been given an ad hoc reporting tool from another individual that has successfully deployed it to the field. He uses Web Logic servers and an Oracle database.
I tried to deploy the same application in my local environment (WAS 7 and Oracle). The first report runs flawlessly. However, when I run the second (or third or fourth) report, I get a very strange error: the second report is appended to the first report.
There is nothing in the code to account for this. This problem can be temporarily solved by stopping and starting the servers every time a report is run (obviously not a real solution). I think this has something to do with data sources and cached information. I then took a step back and tried to deploy it to a Tomcat server. It works perfectly, just like it does in the field. So my question is: are there any known issues between WAS 7 and Oracle 11g that could be causing this kind of problem? Any information would be very helpful.
Please ask about any specifics you may want to know and I will do my best to provide that information.
Thank you for your time.
EDIT: For anyone else looking into this, the problem was due to an incompatibility with the proprietary Oracle calls and Websphere. Once the application was edited to use only JDBC calls, everything works perfectly. Thanks.
This ended up being a incompatibility with using proprietary Oracle calls and Websphere. It was fixed by changing all of proprietary call to normal JDBC calls.
When starting the Purge Tool from the Content Manager server, nothing happens except I just get a 100% CPU process which kills my server instantly, any suggestions?
It's the first time I've executed this tool so I'm not sure what's supposed to happen; does it connect to the DB immediately? - the 190 GB DB I'm lumbered with might not be helping it if that's the case.
Thanks in advance.
I have also seen this in past, you may try this with publication by publication or with limited number of folders/structure group.
Yes purge tool use the database immediately.
You should get a dialog box - It can take a while to load, but in the past I have seen this to be a permissions problem. Try right-clicking on the program, and using "Run as Administrator" if you are on a Windows 2008 Server
The Purge tool starts out by trying to "consume" your blueprint structure. It does this in a pretty cumbersome way however, it will get there in the end. Just leave it to run, it will get there.
The Purge tool doesn't connect to the db directly. It uses the Tridion API. (Of course, Tridion then goes to the database.)
On starting, the Purge tool will load all your publications, which it then displays for you. If you have a lot of publications, and a slow system, this can take a while.
If there is a permissions problem, I'd expect it to be one of Tridion permissions, so ensure that the account you are running as it a Tridion administrator.
I've promised to take a look at an old DotNetNuke installation for a client with the intention of making a few, hopefully minor, changes. The installation is rather old - I believe version 3.0.013 - and the production copy is running against SQL Server 2000, Windows 2003 and .Net 1.1.
As the production server is live and significantly used we need a development installation first. I have attempted to install a copy on my local server - Windows 2003, SQL Server 2005, .Net 2.0, and although with a few tweaks I can successfully get it to display the site, I cannot login, or even access the login module (ie just putting in blank username and password attempting to generate a 'must enter username' type error) without getting the error 'Object reference not set to an instance of an object'
I've spent some time trying to get around this error, without success, although I am hampered by not having used this package before.
So my questions are
Has anyone managed to run DotNetNuke 3.0.x with this configuration (or do I need to setup a box with SQL 2000 and .Net 1.0 to get it to run)?
Any suggestions where I should start looking for this error, or has anyone come across anything similar before?
EDIT: Eventually chickened out and installed in on an old webserver with Win2003/SQL 2000/Net 1.1 and it went in fine on an identical install. So I guess the answer is no, it doesn't work straight out of the box.
My feeling is that you shouldn't have any trouble running in the above mentioned environment. But taking a closer look at the error itself will help us to prove that.
If the error is occurring only when you navigate to the Login module, it may be an issue loading the authentication provider. The best way to find out is to look in the DNN Event Log and take a look at the full error message.
Because you can't login to access the Event Log, you should probably just take a look at the row created in the database when you receive the error. The table is called EventLog and there may be a little bit of friction in parsing the error message out, as all of the details are stored in the database in an XML format.
In general, when moving a site from one environment to another there are only a couple of things that you'd need to do:
make sure you can connect to the database
set the file system permissions
It sounds like you already have database connectivity because you can load the site.
However, you may want to double check (just re-apply) the file system permissions for the root of the website on the machine in question. Make sure the identity of the website (typically ASP.NET Machine Account or Network Service) has 'Modify' permissions on the root website directory. Perhaps the web site can't load a particular assembly due to lack of permissions.