locked
Cannot use domain accounts RRS feed

  • Question

  • Hello everybody,

    I have tried to test the FSCT for a few days on a minimum configuration (one DC, one FS, one Controller, 2 clients, one network).
    All went fine initialising the configuration (using the examples FSCTStepbyStepGuide.doc) but i had no luck when I tried to run a test.

    The output I get on the client is:

    C:\fsct>fsct run client /controller cntr /server fs /password 12345678 /domain TEST
    controller's name: cntr
    server's name: fs
    server's password: 12345678
    domain: TEST
    Using default timeout of 2 minutes.
    Running test.
    Connection to \\fsu1\fsroot1\CLI2u1 failed (try 1 of 5).
    Connection to \\fsu1\fsroot1\CLI2u1 failed (try 2 of 5).
    Connection to \\fsu1\fsroot1\CLI2u1 failed (try 3 of 5).
    Connection to \\fsu1\fsroot1\CLI2u1 failed (try 4 of 5).
    Connection to \\fsu1\fsroot1\CLI2u1 failed (try 5 of 5).
    Error running test. Connect to \\fsu1\fsroot1\CLI2u1 using password: 12345678 failed [error code: 1326].
    Error starting users.
    Error initializing iteration.
    Skipping waiting for user: CLI2u1 as it didn't start correctly.
    Error running client.
    Closing network connection
    Command execution failed.

    The output I get on the controller is:

    C:\fsct>fsct run controller /server 10.0.0.11 /password 12345678 /volumes T: /cl
    ients cli1,cli2 /min_users 2 /max_users 5 /step 2 /duration 120 /workload HomeFo
    lders
    server's name: 10.0.0.11
    server's password: 12345678
    volumes: T:
    clients' names: cli1,cli2
    min users: 2
    max users: 5
    sweep step: 2
    test's duration: 120
    workload to use: HomeFolders
    Executing: rd /s /q running
    Executing: rd /s /q running complete.
    Executing: md running\signals
    Executing: md running\signals complete.
    Running the test (workload: HomeFolders).
    Running iteration for 120 seconds with 2 users [warmup: 30s].
    Performance Counter thread started for 10.0.0.11
    Performance Counter thread started for cli1
    Performance Counter thread started for cli2
    Error receiving message.
    Unknown winsock error.
    Error receiving 'ready' message.
    Error waiting for client cli1 to get ready.
    Error initializing iteration.
    Error running iteration.
    Error running test.
    Error running the controller.
    Closing network connection
    Command execution failed.


    The only thing that solved the problem was creating "by hand" the users locally on the fileserver.

    Do you have any idea why it doesn't use the AD users? Have I forgot/missused a switch?

    Thank you!
    Friday, November 27, 2009 4:08 PM

Answers

  • I have finally managed to run the test.
    - I logged on the client machine with the domain admin
    - i have opened an cmd windows
    - I have successfully executed "runas /user:cli1u1@test.lan cmd"
    - in the opened cmd (running as cli1u1) I have successfully connected to the share (net use) and listed the containing files

    The same test works fine if I log on the client machine with cli1u1 and access the share from the Explorer.

    Regards!
    Monday, December 7, 2009 4:07 PM

All replies

  • Hello,

    Error code 1326 means invalid user name of bad password. Any chance that the domains users were created with another password 12345678.
    Do the password policy in place at domain-level allow such a password?

    Do you see any error in the System log of the clients?



    --- Marc Lognoul [MCSE, MCTS, MVP] Heureux celui qui a pu pénétrer les causes secrètes des choses Happy is the one who could enter the secret causes of things Blog EN: http://www.marc-antho-etc.net/blog/ Blog FR: http://www.marc-antho-etc.net/blogfr/
    Monday, November 30, 2009 3:08 PM
  • Hello Marc,

    I've looked up the 1326 code and found out that it was related to a authentication problem.
    I didn't found any errors in the Event Logs (i have checked all the computers in the setup, I have even turned on the auditing on the shared folder to see if there are any errors).

    After finding what 1326 ment I tried to log on a client computer with an account (cli1u1) but it didn't work.
    I have reset the password on the account and it worked. One strange thing was that the "User logon name" on all the accounts was blank. Only the Pre-Windows 2000 was populated with the right name.
    After logging on the client computer (with cli1u1) I tried to access the shared folder and it worked  (\\fsu1\fsroot1\cli1u1\).

    Re-running the tests gave me the same error.

    Best regards,
    Ionut
    Monday, November 30, 2009 3:27 PM
  • Hello,

    According to your feedback (missing User Principal Name = User Logon Name); the conclusion I come to is that username/password were correct but because the UPN was missing, Kerberos authentication could not be negotiated and therefore an identical error code was returned but for a different root cause.

    Missing UPN sometimes occur when the user is created using the NET USE command.

    On FSU1, do you see something in the Security Event Log related to the error?
    You can also try to stop all open sessions on FSU1 by executing NET SESSION /DELETE before conducting the test again.






    --- Marc Lognoul [MCSE, MCTS, MVP] Heureux celui qui a pu pénétrer les causes secrètes des choses Happy is the one who could enter the secret causes of things Blog EN: http://www.marc-antho-etc.net/blog/ Blog FR: http://www.marc-antho-etc.net/blogfr/
    Monday, November 30, 2009 4:47 PM
  • Actually you don't need a DC to use fsct, it can also work in a workgroup environment.

    In your configuration, are all machines joined to a domain? Could you share the output from "fsct prepare server..."? You might want to add "/verbose debug /timestamps" switches to get a more detailed output. Don't use the "/verbose debug" during an actual run as it will influence the results.

    bn

    Tuesday, December 1, 2009 5:35 PM
  • Hi Marc,

    I have configured the UPN and the user logon name by hand. Then I have reset the passwords on all the accounts with the right one.
    In the end I recieved the same error on the clients.

    Regards,
    Ionut
    Wednesday, December 2, 2009 12:42 PM
  • Hello,

    I'll clean the fileserver, re-run the command and get back to you with the output.

    Regards!

    Wednesday, December 2, 2009 12:44 PM
  • Here is the command output:

    C:\fsct>fsct prepare server /clients cli1,cli2 /password 12345678 /users 10 /domain TEST /volumes T: /workload HomeFolders /verbose debug /timestamps


    clients' names: cli1,cli2
    password: 12345678
    number of users per client: 10
    domain: TEST
    volumes: T:
    workload name: HomeFolders
    timestamps will be added to each displayed message
    2009/12/02 18:58:13 Disabling strict name checking.
    2009/12/02 18:58:13 Formatting drive T:.
    2009/12/02 18:58:15 Format complete.
    2009/12/02 18:58:15 Deleting all net sessions.
    2009/12/02 18:58:15 Stopping service Browser
    2009/12/02 18:58:15 Stopping service LanmanServer
    2009/12/02 18:58:18 Service stopped.
    2009/12/02 18:58:18 Starting service LanmanServer
    2009/12/02 18:58:21 Service started.
    2009/12/02 18:58:21 Creating file sets
    2009/12/02 18:58:21 Creating directory: T:\cli1u1
    2009/12/02 18:58:21 Setting permissions of T:\cli1u1.
    2009/12/02 18:58:21 Creating directory: T:\cli1u1\static.

    .... the files are created...

    2009/12/02 19:00:48 Server setup complete.
    2009/12/02 19:00:48 Closing network connection
    2009/12/02 19:00:48 Command execution completed successfully.

    Wednesday, December 2, 2009 5:06 PM
  • Your output looks correct. All created files should be owned by your domain users. You might want to check that on a couple of them. If that's fine, try doing one more thing:

    - go to your client machine and log on as administrator
    - use the runas command to start a cmd window as one of your domain users: "runas /user:test\cli1u1 cmd.exe". If you're not able to do this, check if the password you've used complies with your password policy. You can hit some issues if it's too simple (you shouldn't be able to create user accounts with a password that doesn't match the policy but it doesn't hurt to check)
    - try accessing fsroot1 share on your server ("dir \\fs\fsroot1" will do)

    bn

    Wednesday, December 2, 2009 11:38 PM
  • I have finally managed to run the test.
    - I logged on the client machine with the domain admin
    - i have opened an cmd windows
    - I have successfully executed "runas /user:cli1u1@test.lan cmd"
    - in the opened cmd (running as cli1u1) I have successfully connected to the share (net use) and listed the containing files

    The same test works fine if I log on the client machine with cli1u1 and access the share from the Explorer.

    Regards!
    Monday, December 7, 2009 4:07 PM
  • Hello everybody,

    & Thanks for your help!
    We decided to run the load testing with local users.

    If you have any updates please keep me informed.

    Best regards,
    Ionut
    Thursday, December 10, 2009 8:37 AM
  • Had a similar issue and ended up putting all the test users in the domain admin group. 
    I also had to allow NTLM authentication on the server, the problem is FSCT uses alias to attach to the server but kerberos doesn't like that, there is a reg key to help with kerberos strict name checking.

    I Haven't had the chance to triage this more but it worked :D

    Next stop FSCT + PowerShell .... mmmmmmm

    It would be nice if there was more flexibility with FSCT to help binding with PoSH ala:


    Test users in specific OU

    Share names of our choice

    scripted dynamic workload profiles .... mmmmm
    Tuesday, December 15, 2009 12:46 AM
  • Doesn't FSCT disable strict name checking during prepare phase on the fileserver?

    As you see in my previous post:

    "2009/12/02 18:58:13 Disabling strict name checking."

    Saturday, December 19, 2009 7:15 AM