From: Tony Toews [MVP] on
Folks

For putting some restrictions on licensing a utility to businesses I'd
like to include the server name in the license key so if it changes
they need to contact me.

Do the various API calls at vbnet.mvps.org such as the following work
on Linux or Novell Netware servers? Hmm, Novell seems to exist but
it looks like maybe Netware is extinct.

NetGetJoinInformation: Join Information for a Local or Remote Machine
<http://vbnet.mvps.org/code/network/netgetjoininformation.htm>


NetServerEnum: Get Version Info for Domain/Workgroup Servers and
Machines
<http://vbnet.mvps.org/code/network/netserverenumver.htm>

NetServerEnum: Obtain Domain/Workgroup Servers and Machines
<http://vbnet.mvps.org/code/network/netserverenum.htm>

That said I suspect I won't get many such as this utility is for
Access. I'm also just started adding some functionality for which I'd
like to get paid as this utility has been a few download since about
2001. www.autofeupdater.com if any one is interested.

The next question though is such a restriction even necessary? My
utility is being used in many organizations around the world including
Fortune 10 companies. So if it's run in ten different departments on
ten different servers then I see no reason why I should sell them one
license key with just their overall business name in it. I'd like
some money at least for all ten servers.

Hmm, ,maybe I should have a two line business name for the business
group and location and such to narrow down where the license is for.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/
From: Richard Mueller [MVP] on

"Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message
news:r4ajb5ppdu240775e3lel6pl56al0ufov1(a)4ax.com...
> Folks
>
> For putting some restrictions on licensing a utility to businesses I'd
> like to include the server name in the license key so if it changes
> they need to contact me.
>
> Do the various API calls at vbnet.mvps.org such as the following work
> on Linux or Novell Netware servers? Hmm, Novell seems to exist but
> it looks like maybe Netware is extinct.
>
> NetGetJoinInformation: Join Information for a Local or Remote Machine
> <http://vbnet.mvps.org/code/network/netgetjoininformation.htm>
>
>
> NetServerEnum: Get Version Info for Domain/Workgroup Servers and
> Machines
> <http://vbnet.mvps.org/code/network/netserverenumver.htm>
>
> NetServerEnum: Obtain Domain/Workgroup Servers and Machines
> <http://vbnet.mvps.org/code/network/netserverenum.htm>
>
> That said I suspect I won't get many such as this utility is for
> Access. I'm also just started adding some functionality for which I'd
> like to get paid as this utility has been a few download since about
> 2001. www.autofeupdater.com if any one is interested.
>
> The next question though is such a restriction even necessary? My
> utility is being used in many organizations around the world including
> Fortune 10 companies. So if it's run in ten different departments on
> ten different servers then I see no reason why I should sell them one
> license key with just their overall business name in it. I'd like
> some money at least for all ten servers.
>
> Hmm, ,maybe I should have a two line business name for the business
> group and location and such to narrow down where the license is for.
>
> Tony
> --
> Tony Toews, Microsoft Access MVP
> Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
> Granite Fleet Manager http://www.granitefleet.com/

I believe the api's are implemented in netapi32.dll, which I suspect is only
in Microsoft Windows OS's. However, the RootDSE object is an industry
standard for all LDAP compliant servers. Among the properties of this object
are defaultNamingContext, serverName, dsServiceName, and dnsHostName. See
this link:

http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx

Of course, any method to retrieve a server name will most likely retrieve
the name of the server the client machine authenticated to when it started.
This could be a different server each time. Would the DNS name of the domain
(the defaultNamingContext property of the RootDSE object) work better? If
your utility only runs on servers, then you want the name of the local
computer. If the utility runs on any client, any call for the name of a
server could return any one of many names, unless there is just one DC in
the local site.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--


From: Richard Mueller [MVP] on

"Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote in
message news:u4q63dGPKHA.5108(a)TK2MSFTNGP02.phx.gbl...
>
> "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in message
> news:r4ajb5ppdu240775e3lel6pl56al0ufov1(a)4ax.com...
>> Folks
>>
>> For putting some restrictions on licensing a utility to businesses I'd
>> like to include the server name in the license key so if it changes
>> they need to contact me.
>>
>> Do the various API calls at vbnet.mvps.org such as the following work
>> on Linux or Novell Netware servers? Hmm, Novell seems to exist but
>> it looks like maybe Netware is extinct.
>>
>> NetGetJoinInformation: Join Information for a Local or Remote Machine
>> <http://vbnet.mvps.org/code/network/netgetjoininformation.htm>
>>
>>
>> NetServerEnum: Get Version Info for Domain/Workgroup Servers and
>> Machines
>> <http://vbnet.mvps.org/code/network/netserverenumver.htm>
>>
>> NetServerEnum: Obtain Domain/Workgroup Servers and Machines
>> <http://vbnet.mvps.org/code/network/netserverenum.htm>
>>
>> That said I suspect I won't get many such as this utility is for
>> Access. I'm also just started adding some functionality for which I'd
>> like to get paid as this utility has been a few download since about
>> 2001. www.autofeupdater.com if any one is interested.
>>
>> The next question though is such a restriction even necessary? My
>> utility is being used in many organizations around the world including
>> Fortune 10 companies. So if it's run in ten different departments on
>> ten different servers then I see no reason why I should sell them one
>> license key with just their overall business name in it. I'd like
>> some money at least for all ten servers.
>>
>> Hmm, ,maybe I should have a two line business name for the business
>> group and location and such to narrow down where the license is for.
>>
>> Tony
>> --
>> Tony Toews, Microsoft Access MVP
>> Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
>> Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
>> Granite Fleet Manager http://www.granitefleet.com/
>
> I believe the api's are implemented in netapi32.dll, which I suspect is
> only in Microsoft Windows OS's. However, the RootDSE object is an industry
> standard for all LDAP compliant servers. Among the properties of this
> object are defaultNamingContext, serverName, dsServiceName, and
> dnsHostName. See this link:
>
> http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx
>
> Of course, any method to retrieve a server name will most likely retrieve
> the name of the server the client machine authenticated to when it
> started. This could be a different server each time. Would the DNS name of
> the domain (the defaultNamingContext property of the RootDSE object) work
> better? If your utility only runs on servers, then you want the name of
> the local computer. If the utility runs on any client, any call for the
> name of a server could return any one of many names, unless there is just
> one DC in the local site.
>
> --
> Richard Mueller
> MVP Directory Services
> Hilltop Lab - http://www.rlmueller.net
> --
>

You may need to describe your architecture. Thinking more about your
question, I wonder if by "server" you mean the computer where your Access
database resides. It may be a Domain Controller, a member server, or an XP
workstation. Perhaps you want to enforce one database per license, but not
restrict the number of clients that can run your application and access the
database.

With an SQL Server database one approach is to publish the application in
Active Directory. SQL Server has one stored procedure to publish the SQL
Server instance and another to publish a database. This creates objects in
the computer object (the computer object acts as a container). This makes it
easy for an application to query Active Directory for objects of the correct
class with the name of your application and retrieve the name of the
computer so you can construct a connection string to connect to the
database. If the application finds more than one, it knows the database has
been installed on more than one computer. Something similar could be done
for an Access database, but of course this would only apply to customers
with Active Directory.

The only other way I can see for the client application to find the server
(assuming client server setup) is to store the name of the server (the
computer with the database) in the local registry, perhaps during setup.
Otherwise the application must assume that the database is on the same
computer, in which case it is easy to retrieve the name of the local
computer.

--
Richard Mueller
MVP Directory Services
Hilltop Lab - http://www.rlmueller.net
--


From: Tony Toews [MVP] on
"Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote:

>You may need to describe your architecture.

Well, that's just it. My VB6 utility runs on all kinds of servers
although mostly Windows servers. So I don't know what server
architecture my utility runs on.

>Thinking more about your
>question, I wonder if by "server" you mean the computer where your Access
>database resides. It may be a Domain Controller, a member server, or an XP
>workstation.

Correct, that's more what I was thinking. I was thinking of putting in
a license check for the Active Directory domain name (or something
similar) and the Server name on which the utility resides.

But then I got to thinking about Novell and Unix networks. Now there
won't be too many of those running Access apps (which is what my
utility assists with) but there will be some.

>Perhaps you want to enforce one database per license, but not
>restrict the number of clients that can run your application and access the
>database.

Well, I'm happy with my utility being used on many Access databases.
It's the servers I'm more interested in.

>With an SQL Server database one approach is to publish the application in
>Active Directory. SQL Server has one stored procedure to publish the SQL
>Server instance and another to publish a database. This creates objects in
>the computer object (the computer object acts as a container). This makes it
>easy for an application to query Active Directory for objects of the correct
>class with the name of your application and retrieve the name of the
>computer so you can construct a connection string to connect to the
>database. If the application finds more than one, it knows the database has
>been installed on more than one computer. Something similar could be done
>for an Access database, but of course this would only apply to customers
>with Active Directory.

Ahh, interesting. Thanks for that idea.

>The only other way I can see for the client application to find the server
>(assuming client server setup) is to store the name of the server (the
>computer with the database) in the local registry, perhaps during setup.
>Otherwise the application must assume that the database is on the same
>computer, in which case it is easy to retrieve the name of the local
>computer.

Well, the user has to store some settings in an INI file on the server
from which my utility runs. So even if the share is a drive letter I
can still get the UNC name of the server and share. So at least I'd
get that server name.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/
From: Tony Toews [MVP] on
"Richard Mueller [MVP]" <rlmueller-nospam(a)ameritech.nospam.net> wrote:

>I believe the api's are implemented in netapi32.dll, which I suspect is only
>in Microsoft Windows OS's. However, the RootDSE object is an industry
>standard for all LDAP compliant servers. Among the properties of this object
>are defaultNamingContext, serverName, dsServiceName, and dnsHostName. See
>this link:
>
>http://msdn.microsoft.com/en-us/library/ms684291(VS.85).aspx

Ahh, that helps.

I do have one client to which I login on a regular basis running a
complete Win 2008 Server with Active Directory and so forth. One
thing I've noticed is that to hit his network I have to enter a domain
name on the VPN which he has setup as "xx.local". where xx are the
initials of his employers business name.

Now knowing him he's done things the right way and I should consider
using that field as one of my licensing limiters.

>Of course, any method to retrieve a server name will most likely retrieve
>the name of the server the client machine authenticated to when it started.
>This could be a different server each time. Would the DNS name of the domain
>(the defaultNamingContext property of the RootDSE object) work better? If
>your utility only runs on servers, then you want the name of the local
>computer. If the utility runs on any client, any call for the name of a
>server could return any one of many names, unless there is just one DC in
>the local site.

I'll copy a portion of my reply to your other posting.

Well, the user has to store some settings in an INI file on the server
from which my utility runs. So even if the share is a drive letter I
can still get the UNC name of the server and share. So at least I'd
get that server name.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
Granite Fleet Manager http://www.granitefleet.com/