Author Posts

February 13, 2018 at 6:28 pm

Hi All,

I know this is a PowerShell forum, but Powershell is wrapped in .NET... so hey *shrug* :). (sorry if this isn't the right place to ask this question. I'm still fairly new to this forum).

I'm brainstorming to create an app (first app that I've thought about creating). Essentially what I would like to do is create a Windows form. This Form would be for HR to type in new employee info. This new employee info Form could contain things like username, first name, last name, office location, etc. THEN, what HR has written the strings containing the info and they click the magical "OK" button on the Windows Form, it kicks out to AD and creates the user and all of their info. This kills two birds with one stone. The new user is added, desktop support folks don't have to worry about new user creation, and we can properly export the info somehow in a pretty Excel spreadsheet for HR purposes.

Now my question is, do you feel that this would be better served in C# or PowerShell? (keep in mind, I have limited C# experience, so this would be a "learn as I go" kind of project). I know that it's possible in PowerShell, as I've created basic forms, but would this be better served in C# ?. Create the back end Windows console in Visual Studio, then put a Windows Form on top so there's a GUI for HR?

Thoughts? Feel free to ask me any questions you'd like.

February 13, 2018 at 6:52 pm

A question that may or may not be helpful... Do you trust your HR department to correctly enter in the information to create user accounts without a review by an IT security person?

Unless you're going to give the HR person permissions to create user accounts in AD, you will need two separate steps – a form that HR enters data into and something to initiate the actual creation by some admin user.

I don't know any C#, but if I had to do this, I'd probably have one of our developers create that form in VS, put the data in a SQL database (or CSV file, or something), and write a script to pull the data for new users, validate that the data is clean, and run the PowerShell to create the user.

February 13, 2018 at 6:57 pm

We get the AD user information fro HR, so yes, I trust that they can copy the info they essentially already have. We could look it over, but if there are any misspellings, it we would have the same typos because we get it from them.

HR wouldn't need access to create AD accounts. I could embed a service account and password into the script that has access to create accounts. Once the app is ran, it would essentially be ran under that service account.

February 14, 2018 at 3:27 pm

As for the original question of language, especially for someone learning, the AD Commandlets provided for Powershell make this a fairly easy task. I would also advise against letting them create the accounts directly. Yes, the typos will be the same, but HR people won't think twice about creating 2 or 3 copies of the account try to get it "just right". So now you have to let them edit to prevent that and things get more complicated. Better to just give them a database table that also acts as a central HR database. Then you can pull creates/updates out of their data.

February 14, 2018 at 3:32 pm

Sorry, I should've been more clear Ron. PowerShell code I write frequently. The more learning curve would be C#.

That's a thought, but it would be nice for them to have some sort of form that gets kicked to AD. As far as typing things in 2-3 times, I can't entirely say that I'd agree. Not sure what they would type in multiple times.

February 15, 2018 at 2:07 pm

Maybe I'm overly cynical about HR people (but probably not), I imagine their thought process works like this:

"Cool, I can create accounts myself now!"
* Creates account JSmith
"Darn, I should have put his middle initial in there... oh well, I won't bother Mike"
* Creates account JTSmith
"Oops, forgot to put his cell number in there instead of his desk phone"
* Creates account JTSmith2

And so on...

February 15, 2018 at 2:20 pm

Well, maybe that could happen.. but I don't want to base anything on assumptions. That's never the way to go.

Any other feedback regarding the topic itself?

February 15, 2018 at 2:47 pm

Just a thought, do your HR already have some sort of database that they enter new starter info into for pay role etc ? If so your script could read data from this and create the accounts ? either as a scheduled task or a manual job.