Timeline for Data Collection reports fail because login is from an untrusted domain
Current License: CC BY-SA 3.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 27, 2012 at 14:53 | vote | accept | gemisigo | ||
| Jul 26, 2012 at 4:36 | history | tweeted | twitter.com/#!/StackDBAs/status/228347924600471552 | ||
| Jul 26, 2012 at 1:01 | answer | added | Jon Seigel | timeline score: 1 | |
| Jul 26, 2012 at 1:01 | history | edited | Jon Seigel | CC BY-SA 3.0 |
Remove sig; edited tags
|
| Jul 25, 2012 at 18:11 | comment | added | gemisigo | let us continue this discussion in chat | |
| Jul 25, 2012 at 17:56 | comment | added | gemisigo | Oh, okay, it's clear now :) That's not possible at the moment. The SQL box was reached through a remote desktop connection by another developer when I asked him to try it locally. I've no direct access to the box itself, no account, no password whatsoever. Also, I didn't know it was possible to start an application on a computer using a login from another machine/domain!? Why is that necessary? | |
| Jul 25, 2012 at 17:22 | comment | added | Jon Seigel | You said that running the reports directly on the SQL box works, correct? To do that, I assume you had to log in to the SQL box using a different Windows account than you use on your workstation. Use the instructions I provided a few comments back to start Management Studio running under that same account. | |
| Jul 25, 2012 at 17:02 | comment | added | gemisigo | I'm afraid I don't understand what you're trying to suggest me to do :( There are no different Windows accs on the workstation. And there are no SQL servers installed on it either, it only has the Management Studio. Its sole purpose is to connect to SQL Servers on different networks. Both reports (Data Collection or otherwise) are invoked on the workstation and fetch data from other machine. With the only difference that one of them works while the other one does not. | |
| Jul 25, 2012 at 16:55 | comment | added | Jon Seigel | Right, but when you run the reports locally (they work), you log in using a different Windows account (correct?). Try starting Management Studio using that account like I suggested and see what happens -- there are other features in SQL Server that grab that information (Maitenance Plans, for example) when you don't expect it. | |
| Jul 25, 2012 at 16:50 | comment | added | gemisigo | That's why I find this weird. I'm not using Windows Authentication and I don't even know how it gets involved here. The SQL Server is running on a computer on the network of the other company. The network of our company is connected to that one using VPN. The workstation is on the network of our company but it is using a local account (I don't know if that's important or not). Management Studio is running on this machine and it connects to the SQL Server using an SQL Login. Other reports (like those for the server itself or for databases) are running properly. | |
| Jul 25, 2012 at 13:03 | comment | added | Jon Seigel | Oh right, Data Collector, sorry. Hmmm... okay. This is probably a permissions issue with how you're logged into SQL Server. Are you using a SQL login to connect to the server, or Windows Authentication? If it's the latter, try running Management Studio itself under the domain account you use to log in to the SQL Server box (Shift+Right-Click on the shortcut, select Run As Different User) and see if that works. | |
| Jul 25, 2012 at 7:28 | comment | added | gemisigo | I appreciate your inclination to help me, Jon, thank you very much. The reports are (or should) be retrieved by opening Management in Object Explorer, right clicking on Data Collection, then selecting Reports->Management Data Warehouse->Disk Usage Summary (eg.). I've got no knowledge about how the rest internally happens. | |
| Jul 25, 2012 at 1:01 | comment | added | Jon Seigel | Complicated is fine, I just need to understand it. :) How are the reports being run? SSRS? Stored procedures fed into something else? ...? | |
| Jul 24, 2012 at 23:43 | comment | added | gemisigo | The topology is... complicated, at least :) Not only in different domains but the networks belong to different companies as well. The workstation is on the network of the company I work for. The network the SQL Server is on belongs to another company. And to add some more confusion, the workstation is used with a local login. | |
| Jul 24, 2012 at 22:27 | comment | added | Jon Seigel | VPN is a networking construct to join multiple separate networks as if they were one, so that shouldn't affect anything. It's still unclear to me what the domain topology is like on your network... Is the SQL Server box in a different domain than your workstation? | |
| Jul 24, 2012 at 21:54 | comment | added | gemisigo | Thanks for the info, Jon, that's interesting. I wonder why does it not complain about when I'm simply connecting to the server and run a query. Any idea how to solve that? I'm not the sharpest knife in the drawer when it comes to domains :) Is it absolutely necessary for the computers to be in the same domain? What happens when there's VPN involved? | |
| Jul 24, 2012 at 21:36 | comment | added | Jon Seigel | I think it may have something to do with the Windows principal that's implicitly used when you open Management Studio. | |
| Jul 24, 2012 at 21:29 | comment | added | gemisigo | I've got no idea where VPN puts the connecting computer but I suppose they aren't. Otherwise it would not be an untrusted domain, would it? Why is that even important? I'm not trying to use Windows authentication. I guess I'm missing some major details about how this thing works... | |
| Jul 24, 2012 at 13:46 | comment | added | Jon Seigel | Are the two computers in the same domain? | |
| Jul 24, 2012 at 8:04 | history | asked | gemisigo | CC BY-SA 3.0 |