Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have recently been tasked with looking after the user login side of things in our enterprise (Windows clients in Active Directory). We have a system at the moment that uses a VBScript login/loggof script to call a couple of DLL written in Visual Basic 6.

The DLL's actions are controled by some configuration files based on users/groups which is administrated from a central application.

This is quite a good system, but we kind of want to come away from Visual Basic 6 for the DLL's (maybe port them to C++, but then you have to make them COM+ to call them from VBScripts, etc.) and possibly away from VBScript for the actual login scripts themselves.

What are other people using, what can people suggest, etc.?

share|improve this question
    
We're a UNIX shop here ... so, no windows or active directory. We use LDAP for storage and Kerberos for authentication. We are implementing Single-sign on (SSO) these days. –  Nikolas Sakic Jun 23 '10 at 13:40
add comment

2 Answers 2

We have a custom logon processor developed in C#. I certainly would not do this in C++. You can do unmanaged COM interop calls from C#/.Net.

If the configuration is quite elaborate, you probably would not want to do this in PowerShell either. PS may be useful for smaller tasks, but it is not suitable once it grows beyond a certain point.

share|improve this answer
    
i did think about doing it in c#/vb.net but i was a bit bothered about the frameworks being installed on all the clients, how do you make sure its installed? –  beakersoft Jun 16 '10 at 10:20
    
There is a product called Xenocode (spoon.net) that you can use to package your framework app so that it can run on machines without the framework installed. Otherwise, you're probably stuck with unmanaged C++. Yikes. –  Greg Askew Jun 16 '10 at 11:15
    
@Greg: out of interest, what size is the point at which PowerShell is no longer suitable? –  Zayne S Halsall Jun 16 '10 at 11:30
    
I don't think it's necessarily a question of size, but if you are writing a custom command interpreter, it becomes how you unit test, if you want to use DI, all the same questions associated with any other type of application development. Powershell doesn't seem like the best fit for this to me. –  BoxerBucks Jun 16 '10 at 11:55
    
@Zayne: Generally, I would say when a PowerShell script goes over a few hundred lines it can become easier to manage through the development and testing lifecycle/process by using C#. Aside from size, it's easier and cleaner to do most of this in C#, and there are a wealth of development resources compared to PowerShell. –  Greg Askew Jun 16 '10 at 12:20
show 3 more comments

Well, what do you want/need to achieve with the script? This'll determine how involved it needs to be.

In our setup, our requirement is merely for a few mapped drives on the clients, and a BGInfo on the servers.

For that, we have a couple of WSH VB scripts on netlogon, and call them from GPOs attached to the appropriate OUs (servers OU on server startup, and users OU on user login).

Scripts are maybe 20 lines a piece. Powershell is a logical next-step, but I'm not impressed with it so far. It feels inelegant and clunky.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.