locked
read AD in domain other than the one I'm logged into RRS feed

  • Question

  • I have a script that I wrote or macro, in Excel that will tell me what OU a server is in. I provide this to users who don't have any other way to know what their server's OU is. Our company has multiple domains. My script only works for the domain the user is logged into. Is there something that I can add so that the script would work in other domains, which have 2 way trusts?  Below is the script that I use.  FYI, at the end of the script I change the backwards output to an easier to read path output, in case anyone wants to use it.  Also, the first section of Constants, I put in all my scripts so I don't have to remember to. 

    I changed the company name and domain for privacy.

    Sub mcrWhatOU()
    On Error Resume Next

    Const ForReading = 1, ForWriting = 2, ForAppending = 8
    Set WshShell = CreateObject("Wscript.Shell")
    Set fso = CreateObject("Scripting.FileSystemObject")
    here = WshShell.CurrentDirectory
    Const OverwriteExisting = True

    '==============Make Connection to Active Directory==============
    Set objConnection = CreateObject("ADODB.Connection")
    Set objCommand = CreateObject("ADODB.Command")
    objConnection.Provider = "ADsDSOObject"
    objConnection.Open "Active Directory Provider"
    Set objCommand.ActiveConnection = objConnection
    '===============End Make Connection=============================

       
            strServerName = Range("B19").Value

            strComputerName = Replace(strServerName, " ", "")
               objCommand.CommandText = "<GC://DC=mydomain,DC=fabricon,DC=com>;(CN=" & strComputerName & ");adspath"
            Set RS = objCommand.Execute

            tname = fso.GetTempName
            TempFile = "c:\temp\" & tname
            Set tx = fso.OpenTextFile(TempFile, ForWriting, True)
               
                While Not RS.EOF
                    tx.writeline RS.Fields(0)
                    RS.MoveNext
                Wend

            tx.Close
           
            Set Results = fso.GetFile(TempFile)
            Set tempstring = Results.OpenAsTextStream(ForReading)
            retString = tempstring.ReadLine

                strCN = Replace(retString, "GC://CN=", "")
                strSeparator = Replace(strCN, ",OU=", "\")
                strDomain = Replace(strSeparator, ",DC=mydomain,DC=fabricon,DC=com", "\mydomain")

                arrValue = Split(strDomain, "\")
                xLen = UBound(arrValue) + 1
                For i = 0 To ((xLen - 1) / 2)
                temp = arrValue(i)
                arrValue(i) = arrValue(xLen - i - 1)
                arrValue(xLen - i - 1) = temp
                Next
                ReverseOU = Join(arrValue, "\")
                Range("C19").Value = ReverseOU
                retString = ""
                tempstring.Close
                Results.Delete
      
    End Sub

    Thursday, June 16, 2016 1:36 PM

Answers

  • closing old thread

    We ended up not using this, which is why I never came back to answer the questions.  I apologize for that.

    • Marked as answer by Carl_S_S Wednesday, October 3, 2018 4:50 PM
    Wednesday, October 3, 2018 4:50 PM

All replies

  • forgot to mention, I've tried changing the domain name in the line "objCommand.CommandText = "<GC://DC=mydomain,DC=fabricon,DC=com>;(CN=" & strComputerName & ");adspath"" to one of the different domains, but it doesn't work.
    Thursday, June 16, 2016 1:45 PM
  • I immediately spotted a rookie line: On Error Resume Next
    In certain circumstances it is very useful but should not be used generally and never without an error handler.

    Next, you don't use Option Explicit

    Both these facts  makes it impossible to know any side-effects of your code.

    Please remove On Error Resume Next and add Option Explicit and Dim all your variables.


    Best regards, George

    Thursday, June 16, 2016 1:59 PM
  • I put On Error Resume Next in the script so that users don't get errors when the server is in a different domain.  I added your recommendations to the top of the script:

    Option Explicit
    Sub mcrWhatOU()
    'On Error Resume Next
    Dim strServerName, strComputerName, tname, TempFile, tx, Results, tempstring, retString, strCN, strSeparator, strDomain
    Dim arrValue, xLen, temp, ReverseOU, WshShell, fso, here, objConnection, objCommand, RS, I

    I changed the domain info to the trusted domain and get this error:

    Run-time error'-2147016661 (8007202b)'

    A referral was returned from the server.

    then when clicking Debug it takes me to the While Not RS.EOF line.

    Thursday, June 16, 2016 3:21 PM
  • BTW, when I keep the domain the same as the one my account is in, I get no errors when searching for a server in my same domain.  SO the error is only when looking in the trusted domain.
    Thursday, June 16, 2016 3:22 PM
  • I'm wondering how you think when you use On Error Resume Next  
    "so that users don't get errors" ...

    it's like driving a car and ignore a flat tire, it can never turn out right.
    If you're a responsible programmer you need to care for ALL errors. Period.

    1. Your DIMs are sloppy, you should tell the compiler what data type each variable is in order to effectively debug your code: Dim strServerName as String etc ...
    2. You need to find out WHY you get the error by experimenting. This forum cannot run code on your domains.


    Best regards, George

    Thursday, June 16, 2016 3:35 PM
  • Why do you feel the need to attack me George?  I'm simply reaching out for assistance from people who know more than me.  Yes feel free to give me constructive criticism.  I'm happy to know that it's important to use Option Explicit or that I should add the data type.  But calling me a rookie, sloppy or irresponsible is uncalled for.  I've taught myself to script and have been doing so for a while.  I write scripts and share with people who don't know how and wouldn't understand the error codes, so I suppress the errors for the end users.  Yes I should rem that out when I'm debugging and usually do.  I did not open this thread because my script wouldn't work and I wasn't getting any errors.  My script runs fine in the domain I'm logged into.  I opened the thread to ask others how I could modify it to query other domains which we have a trust with. 
    Thursday, June 16, 2016 4:11 PM
  • Attack? No way! You just need to learn to avoid the easy way (On Error Resume Next and avoiding Option Explicit). Your programming is sloppy. Shape up and Learn!

    Best regards, George

    Thursday, June 16, 2016 4:17 PM
  • Hi Carl,

    What do you mean with “Server’s OU”?  Which line you got error? Do you mean you want to read AD in domain with VBA?

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Friday, June 17, 2016 7:25 AM
  • The current script reads the entry in Cell B19, searches the DomainA AD domain and returns the OU in which the contents of C19 reside, without error, unless the contents don't exist in DomainA.  You can use it to search for AD groups and users, but we use it mainly for searching for computers.  DomainA is the main domain, this is the one that the users authenticate against.  But we have other domains as well and so far I've been unable to adjust the script to search the other domains, which we have a 2 way trust with, so it's feasible that this can be done.
    Friday, June 17, 2016 12:53 PM
  • Hi Carl,

    Do you mean you could not read ad in other domain from your domain or your code did not work when you move these code in other domains? Could you log on other domain with your credential? If you change the credential with user in other domains, will it work?

    The link below might be useful to you:

    # ADO/AD Query - Permission Denied Issue 

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/e1c8d658-4e9c-4977-9801-4f4a01e084e8/adoad-query-permission-denied-issue?forum=winserverDS

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.


    Monday, June 20, 2016 8:26 AM
  • If you take out the On Error/Resume next, then the code will fail and spit out an error so you have something to debug. With that loop in place, the code just skips over the error and, well, resumes running. In the final code, you may want to use that kind of code but during design, the fail codes are a huge help.

    Whether you build specific error traps instead of a 'resume next' relates to the risk associated with not trapping a failure. You could, at a minimum, pop some kind of error to the user that you can use to debug end use problems or, if there is little risk of problems, use a Resume next and deal with the inevitable user problems by writing custom code that allows you to see the errors.

    Monday, June 20, 2016 4:00 PM
  • closing old thread

    We ended up not using this, which is why I never came back to answer the questions.  I apologize for that.

    • Marked as answer by Carl_S_S Wednesday, October 3, 2018 4:50 PM
    Wednesday, October 3, 2018 4:50 PM