November 2, 2001 at 4:23 pm
I would like to see some information in this area. That is effects on SQL 6.5 - 8.0 running on NT or W2K. Some quick research shows there is not much public info on this subject. There is some speciality Microsoft Q's on replication and clustering issues, but that was all I could find quickly.
November 3, 2001 at 5:40 am
I think the reason you don't find much is that there isn't much. With SQL2K you can publish your publications to AD, that's about it. If you're using AD, then of course 'NT' logins use that, but it's hidden from you (as it should be). There is also an OLEDB provider you can use to query AD as a linked server.
Maybe it's just me, but I've found AD a royal pain to work with. There are different providers, the LDAP syntax sucks, a lot of the properties aren't populated (to boost performance), just not intuitive. Leon and I have both tried it (Leon more so than I) when implementing security in our VB/ASP projects with some success.
I'm sure I could talk Leon into a short how-to on using AD programmatically, could you tell us what kind of info you'd like to see?
Andy
November 3, 2001 at 5:35 pm
Scenario is something like my IT peers want to implement AD in a couple of months. They asked me to certify our SQL environment for the coming migration. We have no replication or clustering and just are scaling up our W2K & S2K systems. Most of our critical apps are NT 4 and SQL 7 SP3.
Now on the programming side I have developer peers that want to query LDAP as if it where any OLE-DB data source. LDAP is no SQL that is for sure. Once you have registered S2K servers and databases in AD, then what? Well maybe not much since there are better ways to get your SQL data than via an LDAP (ADSI) middle man.
We do some technical chores here with keeping our Exchange 5.5 Global Address List (GAL) up to date given our multi-HR environment. Like take our conglumerated people info stuff and push it into Exchange. Also we support other Sites that are going to have the same sort of needs.
Curious to see what they have to say about Yukon at SQL PASS in this AD capabilities vein.
November 3, 2001 at 6:53 pm
Performance is not great from what I've seen. I think it makes sense to pull out the data you need and table it, build some kind of replication scheme to keep it current. Depends on the situation, but often once a day might work, just blow away the contents of the table and rebuild. It is SO much easier. AD is a great idea, but I think (anyone who really knows speak up) it doesnt scale well as far as trying to do a lot of real time queries.
Andy
November 5, 2001 at 8:10 am
Andy, Your suggestion is right on the mark from what I have seen. I'm not sure who started the rumor that AD could be a viable store for data other than that of Security information and machine information gathered by the OS but, they were mistaken as far as I am concerned. Create a database and pull it into SQL on a consistent interval. Query there.
We are using it for one interesting project where we are supporting an internally created applications security within AD and so far it looks like this will fly. Interested to see how the response time will be when 30 people hit it simultaneously....
One side note to comment made by jamyer to Yukon. I thougth I read something about Exchange going to SQL Server backend once Yukon comes out. Has anyone else heard this? I can't find the reference where I saw this so any help would be appreciated.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
November 5, 2001 at 8:39 am
I heard the same thing, no reference handy either. If it happens, definitely changes the role of SQL in the work place.
Andy
November 5, 2001 at 11:47 am
Personally, it seems that not much is being said about AD all around. In fact, the last few .NET presentations I have seen haven't mentioned it at all.
Has anyone completed a migration (running in native mode)?
Steve Jones
November 5, 2001 at 12:24 pm
Andy - Yes it does and for the better (or worse depending on how you are configured). However, it will allow for SQL Server to take a primary highlight role rather than being a back end server. Does that mean I have to speak with management more? 🙁
Steve - Last server goes this week and we will be fully native. I'll post again (unless someone else is already there) just so that I can say yes once that is complete.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
November 5, 2001 at 3:38 pm
We've been running native for quite a while. 8 or 9 servers, 300 or so desktops. No issues. No big gains, other than running Win2K itself - much nicer platform than NT4.
Andy
November 5, 2001 at 4:03 pm
Be interested to hear. We have been all W2K except for the PDC/one BDC for over a year. We love 2K, but have been hesitant to take on the migration since we are < 50 desktops.
Not sure of the benefits, though we would like the practice.
Steve Jones
November 9, 2001 at 2:11 pm
Well, ours is done. We have approximately 100 servers and our last one's to go were Exchange Servers (not my project - Thank you God!). Aside from a great improvement in AD synchronization, I have not seen any difference. However, that difference is significant. A constant pain in the past.
My big complaint with AD / LDAP is in the structure itself. Naming conventions are terrible, structure modification is a fear filled endeavor becuase of the way that it is replicated throughout the server farm, and it does not have any overly friendly user interfaces or nice scripting language (aside from vbscript).
I would love to see the sales presentation that went before MS to sell this as the way to go for the backbone for security architecture storage.
I will be digging into the advantages of native mode as time permits and if I come across anything grand I will be sure to post.
David
David
@SQLTentmaker“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply