SdLogonUserInformation Problem - The list is empty

[Tronex]

I need a setup created with InstallShield 2009 to install a windows service. The service needs an own account to be run under. This accounts needs to be created/selected from within the setup.

For this, I add the corresponding Logon Information Panel dialogs: Dialogs -> All Dialogs -> Right Click -> New Dialog...

On the New Dialog Wizard: Next -> Logon Information Panel and Associated Child Dialogs -> Next -> Finish

However, when I start the setup, and try to browse existing users, it does not matter whether i try to browse Domains, users or whatever, I always get a messagebox saying

"The list is empty.".

Detailed description:

On the Login Information dialog, I click on browse
On the Browse for a user account dialog, I click on browse for the domain or server -> Result: The list is empty.

On the Browse for a user account dialog, I enter the name of the server I am on into the Name of server textbox and click on browse for the user name --> Result: Server not found

On the Browse for a user account dialog, I enter Administrator into the User name textbox while having the name of the server still entered into the Name of server textbox and click on OK --> Result: "Server not found"

After clicking Cancel (back in the Logon Information dialog), I enter SERVERNAME\Administrator into the User name textbox and the corresponding password into the Password textbox and click on Next --> Result: Server not found

I click on New information

I click on Browse for the Domain or Server --> Result: The list is empty.

I click on Browse for the groups --> Result: Server not found

How do I fix this?

[Tronex]

This is really weird. I am constantly getting this problem since IS 2008. Reviewing it and searching for it with google reveals: Most people seem to have this problem.

Also, I did not find ANY reference of any Acresso/Macrovision employee ever helping out with this issue. It is almost as if they dont know themselves what's going on.

Since I believe, the error originates from the custom actions that trigger the verification of the account, Acresso should know what can cause this. Except of course they don't have the sources for the CA's...?

However,... even after paying thousands of Euros for that piece of software, I don't get official support without separate support contract...

So I guess, I will have to code my own CA's. I am thinking about switching to WiX. When I have to code everything on my own anyway, there's no use for something like InstallShield whatsoever...

[Tronex]

I don't know how others think about this, but I always thought, the advantage of using a product such as InstallShield is, that it already includes a lot of solutions that you don't need to invent yourself anymore.

One of those solutions is certainly the LogonInformation Dialog. However, I already explained that I am having problems with using it. Funny enough, no one cares.

The magic question is now whether I need to code an own solution (which I would most probably use Managed Custom Actions for) or if any Acresse developer shows some sort of reaction to the question why InstallShield pops up the message "Empty List" when trying to use the LogonInformation dialog.

[Grimfort]

If its any consolation, I got one working in IS12.

[cbranca]

IS 2008..List is empty when browsing users..
Any ideas are appreciated.

I have had a case open with IS support and am moving at a snails pace. i.e. no idea from them at all. I have not spoken to anyone that knows anything yet....

I got a nice phone call from Randy at Acresso to say they are loooking at it, but other than that I have not heard anything.

[Tronex]

@Grimfort:
Nice to know that it can work. 😉

However, even if it did work for me, I couldn't use it for customer setups, until I knew,why it sometimes does not work.

@Acresso:
Imagine that we deliver a customer setup and that customers calls us asking why the setup does not work. He gets a "list is empty" message. What are we supposed to say then? "Sorry, that can happen under unknown circumstances,... looks like this is the case in your environment. Bad luck, bye."

If we knew what can cause this problem, we could write at least something into the prerequisites/requirements for the setup to work.

[Cary_R]

Hi all,

Just wanted to weigh in on this thread, since I've just finished getting some answers myself on this topic.

Resolving the available domains and their corresponding domain controllers is reliant on NetServerEnum, which has a dependency on the Computer Browser service. So,

1. If you don't have the Computer Browser service enabled
2. If there's no firewall exception for it
3. If broadcast traffic is not enabled on your network (i.e. traffic to x.x.x.255 addresses)
4. If your computer is not a member of a domain
5. If No master browser has been designated on the network (this in theory will correct itself eventually)
6. If NetBIOS over TCP/IP not installed

...Then the LogonInformation dialog is going to have some problems browsing for Domain Controllers and such. It should be noted that these are just the cases that I'm aware of--there may be more still.

This is just for the browsing of domains and domain controllers, though. Validating a user account is a whole other topic by itself, it seems. I've submitted a work order (#IOA-000046275) to help get around a few of these cases (#3 & #4, producing "Server not Found") but as of IS2009 this has not been put in place.

Some notes on determining if these cases apply to you:

For case 3, this will be a problem when the client machine is not on a domain. Then, there's no domain controller to talk to, and broadcast traffic gets sent out to see if anyone replies with their information. You can see this occurring in a Packet Trace with something like Wireshark--it will look like traffic going out to a x.x.x.255 address, and no information coming back at all (an indicator that nobody is hearing the broadcast packet for whatever reason).

For case 5, you can either write a small app that calls the appropriate NetServerEnum call with the SV_TYPE_MASTER_BROWSER flag (as there doesn't appear to be an existing utility out there for this), or you can use the following script to see if the master browser is configured, and actually up and running on the network (which is less elegant):

http://articles.techrepublic.com.com/5100-10878_11-1056129.html

Hope this helps anyone else that's running into issues with this.

[Cary_R]

Might as well post what I came up with for checking to see if you have a valid Master Browser on the network. Here's some InstallScript code to do this in the form of MessageBox()es, based off of the Installsite.org sample for browsing SQL Servers (I believe this works, testing it on a few machines):

[CODE]#include "ifx.h"

#define SV_TYPE_MASTER_BROWSER 262144

// simple server structure
typedef SV
begin
LONG plattform;
LONG name;
end;

// string for servername
typedef SERVERSTR
begin
STRING Server[255];
end;

export prototype MyFunction(HWND);

prototype LONG NETAPI32.NetServerEnum(POINTER, BYVAL LONG, BYREF LONG, BYVAL LONG, BYREF LONG, BYREF LONG, BYVAL LONG, POINTER, BYREF LONG);
prototype LONG NETAPI32.NetApiBufferFree(BYVAL LONG);
prototype LONG Kernel32.lstrlenW(LONG);
prototype LONG Kernel32.RtlMoveMemory(POINTER,NUMBER,BYVAL NUMBER);
prototype LONG Kernel32.WideCharToMultiByte(LONG,LONG,POINTER,LONG,BYREF STRING,LONG,LONG,LONG);

function MyFunction(hMSI)
STRING aktSQLServer[255], svBrowser, svResult;
NUMBER i, nResult, EintraegeGelesen, EintraegeInsg, Handle,Buffer,Laenge,l,pTestStr2;
SV ServerStruktur;
SV POINTER pServerStruktur;
SERVERSTR ServerName;
SERVERSTR POINTER pServerName;
NUMBER nBufferPointer;
LIST ServerList;
begin
pServerStruktur = &ServerStruktur; // points to structure
pServerName = &ServerName;

Handle = 0;
nResult = NetServerEnum( NULL, 100, Buffer, -1, EintraegeGelesen, EintraegeInsg, SV_TYPE_MASTER_BROWSER, NULL, Handle );
nBufferPointer = Buffer;
NumToStr(svResult,nResult);
MessageBox("NetServerEnum Returned: " + svResult,0);
i = 0;
while( i < EintraegeGelesen )
RtlMoveMemory( pServerStruktur, nBufferPointer, 8 ); // copy adress
l = pServerStruktur->name;
Laenge = lstrlenW( l )*2; // calculate stringsize
if Laenge then
RtlMoveMemory( pServerName, l, Laenge); // copy servername
endif;

// Important! Unicode servername convert to ANSI
WideCharToMultiByte( 0, 0, pServerName, -1, aktSQLServer, Laenge/2, NULL, NULL );
nBufferPointer = nBufferPointer + 8; // inc buffer
i++;
MessageBox("Master Brower Computer: " + aktSQLServer,0);
aktSQLServer = ""; // delete last servername
endwhile;

NetApiBufferFree( Buffer ); // free buffer
end;
[/CODE]

[ThisIsEd]

Sorry to drag up an old issue, but sounds like I'm running into a similar problem in our basic msi.

In our install on some machines if we specify username (IS_NET_API_LOGON_USERNAME) such as ".\user" then we get an error about "Server not found"

Snippet from a logfile when this is happening (.\user is a valid local user):
[CODE]MSI (c) (D4:7C) [14:55:53:913]: PROPERTY CHANGE: Modifying IS_NET_API_LOGON_USERNAME property. Its current value is 'domain\username'. Its new value: '.\user'.
MSI (c) (D4:7C) [14:55:57:897]: PROPERTY CHANGE: Adding IS_NET_API_LOGON_PASSWORD property. Its value is '**********'.
MSI (c) (D4:7C) [14:56:07:333]: PROPERTY CHANGE: Adding IS_NET_API_LOGON_PASSWORD_CONFIRM property. Its value is '**********'.
MSI (c) (D4:7C) [14:56:07:469]: Doing action: ISNetValidateLogonName
Action 14:56:07: ISNetValidateLogonName.
Action start 14:56:07: ISNetValidateLogonName.
MSI (c) (D4:7C) [14:56:07:470]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'ISNetValidateLogonName'
MSI (c) (D4:94) [14:56:07:471]: Invoking remote custom action. DLL: C:\Users\elin\AppData\Local\Temp\MSI80B3.tmp, Entrypoint: ISNetValidateLogonName
MSI (c) (D4!64) [14:56:07:479]: PROPERTY CHANGE: Adding IS_NET_API_NET_VALID_USER property. Its value is '0'.
Action ended 14:56:11: ISNetValidateLogonName. Return value 1.
MSI (c) (D4:7C) [14:56:27:382]: Doing action: ISNetValidateLogonName
Action 14:56:27: ISNetValidateLogonName.
Action start 14:56:27: ISNetValidateLogonName.
MSI (c) (D4:7C) [14:56:27:382]: Note: 1: 2235 2: 3: ExtendedType 4: SELECT `Action`,`Type`,`Source`,`Target`, NULL, `ExtendedType` FROM `CustomAction` WHERE `Action` = 'ISNetValidateLogonName'
MSI (c) (D4:80) [14:56:27:384]: Invoking remote custom action. DLL: C:\Users\elin\AppData\Local\Temp\MSICE85.tmp, Entrypoint: ISNetValidateLogonName
Action ended 14:56:29: ISNetValidateLogonName. Return value 1.
Action 14:56:31: CancelSetup. Dialog created[/CODE]

We are using InstallShield 2008, so if this is fixed in a later version, that would be good to know.

Thanks,
Ed

[Cary_R]

Hi Ed,

I'm not certain the .\user syntax is valid for this field (but certainly ODBC drivers take that for a local server, and again in WMI).

The log entries are notoriously un-helpful in this regard, just setting the property that suggests that the user wasn't found (a limitation of custom actions launched from ControlEvents makes it so we get no log entries).

IS2010 I think has some custom actions using dummy properties to write to the logfile, so the same test might give more data at least, but I'd expect the same issue to be present.

Also, I'd recommend just double checking if explicitly using the local machine name in the user field gives the same result. It's possible that it does, and there's some other issue at work, but I would double check this first and foremost.

[Cary_R]

Cary R wrote:
Hi Ed,

I'm not certain the .\user syntax is valid for this field (but certainly ODBC drivers take that for a local server, and again in WMI).

The log entries are notoriously un-helpful in this regard, just setting the property that suggests that the user wasn't found (a limitation of custom actions launched from ControlEvents makes it so we get no log entries).

IS2010 I think has some custom actions using dummy properties to write to the logfile, so the same test might give more data at least, but I'd expect the same issue to be present.

Also, I'd recommend just double checking if explicitly using the local machine name in the user field gives the same result. It's possible that it does, and there's some other issue at work, but I would double check this first and foremost.

Indeed, I just got a free moment to dig into this, and it appears as though the InstallShield custom action that validates the account does not:

--Understand . as the local machine (which makes sense, since this isn't valid syntax except for SQL, and there's no entry in HOSTS for this)
--Resolve Environment Variables
--Resolve MSI properties
--Understand the local TCP loopback (127.0.0.1)

Arguably, some of these make sense. However, they are all very minor tweaks that could make this more usable for end users. I would recommend reaching out to technical support to submit a feature enhancement. 😉

Regards,

Cary