Simple Powershell task, network drive and pst mapping

This topic contains 0 replies, has 1 voice, and was last updated by Profile photo of Forums Archives Forums Archives 5 years, 4 months ago.

  • Author
    Posts
  • #5597

    by sebastienp at 2013-02-26 08:09:02

    Hello folks,

    I've never touched powershell before and i'm trying to accomplish a task without having to use vbs scripts. So i have to look at different options that are available to me.

    Here's is a description of the scenario that i'm trying to accomplish:

    In an active directory environment where our users will be logging in from windows xp(although not for long because of the end of life date of XP), windows 7, windows 8 and a terminal server running on server 2008 R2, I would like to have a powershell logon script do the following 2 tasks:

    1- map network drives based on the username
    2- map a pst file found on the network to the outlook profile of the user logging on the network

    Here are additional details about the 2 task that I'm trying to accomplish:

    1a – A user will have it's network drives mapped based on an Active Directory security group that he is a member of. Here is an example in KixTart:

    IF INGROUP("DomainName\activeDirectorySecurityGroupName") = 1
    USE Q: "\\fichiers1\Departments\Pompiers" /PERSISTENT
    ENDIF

    IF INGROUP("DomainName\Domain Admins") = 1
    USE R: "\\server3\Service des Technologies" /PERSISTENT
    ENDIF

    1b – A user will also have access to a network drive that belongs to him(and not a department network drive as shown above). Mapping this drive is problematic to me, here's a example of something i'm trying:

    (New-Object -Com WScript.Network).MapNetworkDrive("x:" , "\\fichiers1\[Environment]::UserName")

    What i'm looking to accomplish here is: when a user logs on, the drive letter X is assigned to \\fichiers1\%username% on our file server named "fichiers1"

    2- At the moment, pst files are stored locally on the user's desktop. This will change and they will be moved individually to a network location. Assuming that the transfer of these pst files is completed when outlook is not open;therefore, there should be no lock files on the pst, I'm looking for a powershell script that will disconnect the local pst from the user's outlook profile and map the pst that was transferred to a static network location. The network location for the PST files will have the following tree structure:

    \\serverName\PST\%username%

    I would really appreciate feedback on this issue. I can provide more details if they are needed.

    Also... considering this script is possible to create, at which point will it be executed? in active directory there's a profile tab where you can define a profile path, a logon script and a home folder. How can this powershell script be called when a domain user is logging in on the network?

    I look forward to your insight,

    thanks

    -sebastien

    by DonJ at 2013-02-26 09:39:44

    You can map a drive by running NET USE, or in v3.0 by using New-PSDrive with the -Persist switch. Stick with NET USE (which is the old Cmd.exe command you probably know) since XP can't run 3.0.

    Checking group membership can be a bit trickier, since there isn't a core PowerShell command to do so, and you're not going to be able to deploy Microsoft's AD commands to an XP machine. But take a look at http://gallery.technet.microsoft.com/sc ... 7da1cc7df4 – you could probably incorporate that.

    Mucking around with Outlook profiles is tremendously complicated. Don't have an answer for you there, sorry. You will probably need to hunt down some command-line tools that can do this, and PowerShell could run those if you find them.

    Logon scripts execute after the user logs on, as their desktop environment is coming up. One typically uses a GPO to assign logon scripts though. What you're seeing in the AD profile is old, old, old stuff. And keep in mind that PowerShell has to be on the client computer, which isn't the default for XP.

You must be logged in to reply to this topic.