Hi.
I'm doing more and more with powershell (because of our exchange environment) and less and less with VBscript but it seems like there are things that VBScript can do that powershell either can't, or can't do easily.

I'm fudging up a "createuser.ps1" (just to learn how PS works mostly) and I got the microsoft powershell scripting guide and I've googled all over the place. I was hoping someone had a quick how to.

This is a part of my script...

there is a bunch of stuff above this

#profile
$objUser.put("profilePath", "\\VMFPS001\profile$\"+$userid)
$objUser.put("scriptPath", "vmlogon.vbs")
$objUser.put("homeDirectory", "\\VMFPS001\home$\"+$userid)
$objUser.put("homeDrive", "Z:")
#$objUser.setInfo()

#account
$objUser.put("UserPrincipalName", $userid+"@qcl.lan")
#$objUser.setInfo()

There is a bunch of stuff below this but you get the idea.
I used ADSIEdit to get most of the field names but I simply cannot find the field for terminalservicesprofilepath

With VBscript, its actually only a few lines after you bind
tspath="\\XEN001\"& LogonName & "$"
            Set objUser = GetObject("LDAP://cn=" & _
                          FullName & "," & dcroot)
            objUser.TerminalServicesProfilePath = tspath
            objUser.SetInfo


Is there a quick fix for this? Scripting Guys stuff is way to complicated. Thanks in advance.

Well everyone like to use the Quest Tools for AD. http://www.quest.com/powershell/act...erver.aspx
They make it rather easy to manage AD.

if you want to use ADSI lik in VB look how easy it is:

$user = [adsi]"LDAP://cn=user,ou=myusers,dc=example,dc=com"
$user.profilepath = "\\path"
$user.homeDirectory = "\\homepath"
$user.setinfo

So it really is easier using ADSI than VB, just different. Trust me I know what you're saying. I refused to go to PowerShell because I just couldn't get used to PowerShell. But I've been actively using PS since November and I'm loving it. It was a steep learning curve but I find that almost everything is easier to do in PS than in VBscript and PS is SOOO much more powerful.  I just hate that I took so long to move over.

I'm using PowerShell v2 RTM on Windows 7. The new RSAT tool have an AD module that I've been using in my environment. So I won't comment on how to use the Quest tools. I know that the Quest tools are very popular and if you're not http://blog-powershell.blogspot.com...m-and.html">ready to use the Microsoft AD module in your environment then they are the best tools to use.

Hope it helps
Cameron

On the plus side, what I got from Scriptting guys really does work.


function SetTSProperties()
{
 $ou=[ADSI]"LDAP://cn=Users,dc=qcl,dc=lan"
 $user = $ou.psbase.get_children().find($userDN)
 $user.psbase.invokeSet("allowLogon",1)
 $user.psbase.invokeSet("TerminalServicesHomeDirectory",$hDirValue)
 $user.psbase.invokeSet("TerminalServicesProfilePath",$ppValue)
 $user.psbase.invokeSet("TerminalServicesHomeDrive",$hdValue)
 $user.setinfo()
} #end SetTSProperties

function QueryTSProperties()
{
 $ou=[ADSI]"LDAP://cn=Users,dc=qcl,dc=lan"
 $user = $ou.psbase.get_children().find($userDN)
 foreach($property in $aryTSProperties)
 {
  "$($Property) value: $($user.psbase.invokeget($Property))"
 } #end foreach
} #end QueryTSProperties

$userDN = "CN=flast"
$hDirValue = "\\Hamburg\TSUsers\Home\TestUser"
$hdValue = "t:"
$ppValue = "\\Hamburg\TSUsers\Profiles\TestUser"
$aryTSProperties="allowLogon","TerminalServicesHomeDirectory",
  "TerminalServicesHomeDrive","TerminalServicesProfilePath"
SetTSProperties
queryTSProperties

Not sure if it is a version thing.  But I don't need to use the psbase.invokeSet function to set properties in AD.  You should be using PowerShell v2 RTM if you are just starting out.  http://support.microsoft.com/kb/968929

Cameron

Well after doing a bit more research I see that accessing Terminal Services Profile doesn't behave like other AD attributes. Here is a great page on using the Quest tools to access these parameters:

http://dmitrysotnikov.wordpress.com...owershell/
http://dmitrysotnikov.wordpress.com...anagement/

The second URL shows how to access the parameters on an XP or vista workstation.

However, normal AD attributes work as I demonstrated above.