Hi,

I’m trying Tideway foundation community edition in my lab, for the moment.
Discovery is ok for Linux boxes.
I set up a windows credential slave. Its status is connected in the slave management page. There is no firewall on the windows server, neither between the tideway appliance and the windows.
I’ve created a credential “administrator” (administrateur, in fact. I’m french.) in the credentials list with only “windows” access. I tested it with the IP of my slave, it is ok. I have no other windows boxes for the moment but I guess the slave should be able to discover itself.

All discovery status for this windows box are “No Access”.
There must be something I did wrong, but what ?

Hi Frederic. Sometimes this happens to me if administrative shares on the target host are turned off. You can verify this from the command prompt with “net share”:

If the “ADMIN$” share is not available, psexec will fail and we may not be able to discover that host.

It’s also worthwhile to test the commands manually. Open a command prompt, change to the Tideway slave directory (usually C:\Program Files\Tideway Foundation\Credential Slave) and enter this command:

… and you should get the results of the “systeminfo” command with the message “systeminfo exited on TARGET_HOSTNAME with error code 0.” If the errorcode is anything other than 0, we have a problem executing commands, and this will likely result in “No Access.”

Are you able to log into the slave machine with the “administrateur” user? It’s possible that the account is locked out, or is not allowed interactive login. Try these things and let us know. :)

Thanks for the quick answer, Colin.
Unfortunately, this does not solve my problem.

Administrative shares are available.
The psexec command succeeded and gave a lot of info. (using localhost, IP, or hostname as TARGET_HOSTNAME)
And I can log into the slave with the admin account.

I can give you more infos :
The discovery fails during the getInterfaceList step. I tried the psexec command from the slave, and it succeeded (Error code 0) but the standard output has problem with french accents.
Do you think the problem can occur because the engine does not recognise these weird chars ?

Does Tideway foundation works with french os ?

Hi Frederic.

Unfortunately we need the deviceinfo, hostinfo and interfacelist stages to succeed in order to correctly identify which Host node to update; this is why you are seeing the discovery access drop into the “NoAcces” state.

We do use a lot of regex and character matching during the parsing so it is possible that accented characters could be tripping a parser.

Do you have WMI access to this box? That is our preferred method as it is more robust to these issues as we don’t have to parse the command output.

Failing that can you set up an admin level account with the locale set to en? That would help us confirm or exclude the locale as the cause.

I have all access to this lab box. Unfortunately, I am more a Linux guy than a Windows guy.

By the way, as I said, the server I am trying to “discover” is the slave itself, with the local admin account. I assume that this account has all access needed. This system is not “perverted” by other softwares or weirds configuration.
I did a fresh install from Win2K3 with default settings and then followed the steps described in the Online tutorial about windows slaves.

I will :

• see what I can dig about WMI access.
• try to set locale in english.

Again thanks for your help. I’ll keep you informed as soon as I’ve figured out how to do the last 2 points.

Hi Frederic,

This may not be related to the problems you are having but I just thought I would check how the “administrateur” credential has been added to Foundation.

When adding a credential for windows systems it is best that the username is entered in this form (note the caps):

localHost\administrateur

Making use of the AD or Workgroup slaves simplifies this considerably, as you do not need to add a credential at all. But I do understand that this may not be an option for you at this time.

Given that you are getting HostInfo it seems unlikely that my suggestion will change anything, but it is a good habit to get into when adding windows credentials into Foundation.

Andy

As a further thought we normally recommend that a Windows Slave doesn’t try to discover itself. There are subtle differences in the way windows authentication behaves if the access is local and not remote. As the normal use of Foundation is such that the access is remote that is the behaviour we build the Windows Slave to expect.

If you have a second windows machine to run the slave from I’d recommend that.

Andy, indeed, this is not the solution. But, given you said it is better like that, I will keep this way of adding users.
Charles, ok, I’ll install another credential slave right away.

Ok, the new credential slave is up.
I set the WMI permission to “Everyone can do everything”

No improvement. None of the 2 boxes can discover the other.

The new server is FR, to.
I will follow the “locale” lead.
Am I really the first french to use Tideway ?

Thanks for sticking with it, I’ve also followed a few things up here too.

Ipconfig and netstat field names are localised in French so will have issues if we fall back to psexec based discovery, netstat will probably be ok but ipconfig will be in trouble. However we do have Windows machines in non EN locale in the lab and we do discover these successfully via WMI.

I know that we have Foundation deployed in Europe but generally these are along our normal lines of using an AD Slave and therefore WMI access.

One tool we use a lot internally to double check WMI access is the Scriptomatic tool informally maintained by the Microsoft technical team, you can get it and instructions here

We need data from Win32_NetworkAdapterConfiguration and Win32_NetworkAdapter from the CIMv2 namespace.

I see that :

• we all seem to know where the problem is. (good)
• tideway can discover non EN OS. (Good. I was about to doubt)
• you have a solution : using the normal discovery way => WMI

and if I make it quick :

• RCMD (psexec) is a “workaround” when WMI access is not granted.
• WMI Access for local user from other servers can’t be granted. (Can someone with better knowledge tham me confirm that ?)
• RCMD and “credential slave” are used for stand alone servers. (No WMI access possible)
• RCMD (psexec) does not work on non EN OS.

I know what i need to do : get an AD in my lab.

Setting up an AD Slave will mirror the normal recommended deployment of Foundation. If you are testing in the lab to see if you want to use one of the other editions at a larger scale it’s a good step to take.

What version of Windows are you:
a) Running the Windows Slave on?
b) Trying to discover?

The reason I ask is that Microsoft changed some of the permissions around WMI in the Vista/Server 2008 line as part of how they handle remote users under User Access Control (UAC). This is avoided if you use an AD Slave as UAC doesn’t apply authenticating using a domain account with local admin rights.

If your computer is part of a domain, connect to the target computer using a domain account that is in the local Administrators group of the remote computer. Then UAC access token filtering will not affect the domain accounts in the local Administrators group. Do not use a local, nondomain account on the remote computer, even if the account is in the Administrators group.

The summary of this is that the Credential and Workgroup Slave can’t discover Vista/2008 properly via WMI. The fallback methods using psexec also will fail for related reasons and even if they did not I suspect that the data returned from an FR locale machine would not work.

Full details of the UAC behaviour are on MSDN here, and that also details the registry key that can be changed to disable UAC on a machine by machine basis.

Ok, let’s focus on the 2K3 boxes.

I’ve

• set my AD,
• registered another 2K3 server on this domain,
• set the WMI permissions for domain admins on both servers,
• double checked them with scriptomatic (with both Win32_NetworkAdapterConfiguration and Win32_NetworkAdapter classes),
• created a “domain\admin” credential in Tideway,
• uninstalled the credential slave in both boxes,
• removed the corresponding item in Tideway,
• installed the AD slave on the AD controller,
• started it,
• fixed the FW (by stopping it),
• created an AD slave in Tideway with both DNS and Netbios names (Status is “Connected”).

Discovery of the domain controller, by the domain controller (AD Slave) is ko during getInterfaceList.
Discovery of the domain member, by the domain controller (AD slave) is ko during getHostInfo.

I may have missed something. but what ?
This begins to be a bit fustrating.

Apologies for the frustration Frederic. Unfortunately there are just more things that can go wrong discovering Windows compared to Unix, let’s see if we can’t get this resolved.

The normal configuration will be for the AD Slave to be running on a Host that is a member of the domain you want to discover and for that service to be running as an AD Account that is a Domain or Enterprise Admin. There is no need to add any credentials in Foundation as the AD Slave inherits the rights from the user the service runs as.

So the step of creating the credential in your list is not needed, but shouldn’t be an issue if only the AD Slave is connected.

What catches my eye is that you are running the AD Slave on the machine that is the AD Controller. I don’t think we’ve ever tested that configuration as even in our lab we don’t have access to the infrastructure AD controller and it has never cropped up in deployments. I’m pretty sure it’s not an issue but I can’t rule it out.

Can you double check the following things, apologies if this is repeating steps.

1) Is the AD Slave service running as the AD Domain Account user? Can you check the “Log On” tab and ensure its set to “This Account” rather than “Local system account” in the service configuration.

2) Can you log on to the AD Slave Host as the AD Domain Account user and run scriptomatic against the classes. This should exactly replicate the authentication situation the AD Slave will see if it is set up as in check 1

If you get WMI data then something else is up and we’ll take it from there.

Could you also run this query and screenshot the results for me? It will help me understand what state the Windows Hosts in your Foundation instance are in. If you’d rather email me the screenshot direct then I’m happy to pm you my address.

Hopefully we get this resolved shortly.

I’ll do the 2 points as soon as this post is done and the VM is started.
Regarding the query, where can paste it in Tideway ?

Frederic,

at the top right-hand corner of the page there is a search dropdown icon that, when clicked, reveals a menu. On this menu is a link entitled “Generic Query”.
Once you have clicked there, it takes you to a page where you can enter the search query.

I have attached a couple of screen snippits for clarity.

Andy