How to modify $pshome PowerShell 2.0 variable so that it points to a different directory
-
We are using VDI virtual machine desktops, and we are told *not* to write to the C: drive because it will get recreated every time our administrator pushes out a new virtual machine. Unfortunately, the $pshome PowerShell 2.0 variable points to "C:\Windows\System32\WindowsPowerShell\v1.0" [sic], which means that we will lose the contents of the profile script on the next virtual machine rollout if we create a script there.
How can I edit the $pshome variable so that I can point it to a persistent disk instead of the default location on the C: drive? I've tried using the Windows Control Panel to define as an environment variable at a user level (not system level). cmd.exe [sic] can see the variable, but PowerShell refuses to use it. I don't have the required permissions to add a system level variable, but I don't see pshome defined at the system level anyway. However, PowerShell has to be picking up the defintion from somewhere...
Any ideas?
-
I am not sure I can solve the issue by changing where PS will look to load a profile script, but I may have a workaround for you. Since this is a workstation I am not worried about unattended processes. If I should be then this may not work for you. How do you launch your PowerShell consoles? If you use a shortcut you could modify the Target command to include a script to execute...a script that will function to setup your session as a profile script would, like this:
C:\Windows\System32\WindowsPowerShell\v1.0>C:\WINDOWS\system32\windowspowershell\v1.0\powershell.exe -NoExit c:\@\Untitled2.ps1
Just change C:\@\Untitled2.ps1 to something that makes sense on your workstation, on one of your fixed drives.
Then whenever you open a new Console you'll have already run your "profile" script.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato -
Hmmm. Sounds like that would work for batch jobs, but I would like something that would handle interactive commands too (so I can test in the exact same environment that the batch jobs will use).
-
shew (8/13/2011)
Hmmm. Sounds like that would work for batch jobs, but I would like something that would handle interactive commands too (so I can test in the exact same environment that the batch jobs will use).I was actually thinking the shortcut I presented would handle starting an interactive prompt, but not really help with batch 🙂
If you need a consistent environment for both then I would look into something that will replace your profile script after each reboot.
Do you have a local instance of SQL Server Agent running? If so then something like this may work:
1. Store a copy of your profile script on one of your fixed drives.
2. In the Services MMC set the SQL Server Agent service to Automatically start.
3. Create a SQL Server Agent job with a single step in it that copies the profile script from your fixed drive to your $pshome location. This should be a one-liner with PowerShell or CmdShell.
4. Add a schedule to the SQL Agent job with Schedule Type "Start automatically when SQL Server Agent starts".
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato -
I opened a call with Microsoft. They tell me that there is no way to move $pshome in Windows 7 Enterprise and presumably Windows Server 2008. It functions as designed. Sigh...
-
I know it doesn't help but this is one of the many reasons why I try to do as much as possible from T-SQL. 😉
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
I do as well. I primarily use PowerShell to lauch scripts that contain calls to SQLCMD.EXE. In our environment, Task Scheduler is just way easier to manage than a bunch of SQL Server Agent services. I'm sure that is not true for everyone, but for us, Task Manager works well.
-
I've got no problem with that. I've been known to use it myself. It's a tried and true method so long as you're protecting the passwords with either Window's logins or some other secure method.
Thanks for the feedback.
I guess my next question would be... why do you need Powershell to do such a thing?
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
We made a clean cutover to PowerShell when we migrated to SQL Server 2008 a year ago because PowerShell was Microsoft's latest vision of the future. We are a "locked down" hosting facility (xp_commandshell as well as a host of other features is not allowed), and PowerShell gives us access to the Operating System as well as TSQL (via SQLCMD.EXE). PowerShell also lets us move scripts easily between servers and treat the scripts like source code releases. We have an automated script that pushes out new versions of our scripts to the machines that need them. Overall, PowerShell is fairly easy to use, and it is reasonably reliable. At other sites in the past, I have had reliability issues with the SQL Server Agent process failing unexpectedly, so I shied away from it at this site.
-
shew (8/17/2011)
We are a "locked down" hosting facility (xp_commandshell as well as a host of other features is not allowed),Heh... xp_CmdShell. 🙂 One of my favorite points of discussion. I'll start out by saying that unless your "users" have only "PUBLIC" privs (and I mean not even db_DataReader privs) and you can't run xp_CmdShell in a stored proc without users being able to execute xp_CmdShell directly, then you may want to reexamine just how "locked down" you think things actually are.
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
Jeff Moden (8/17/2011)
shew (8/17/2011)
We are a "locked down" hosting facility (xp_commandshell as well as a host of other features is not allowed),Heh... xp_CmdShell. 🙂 One of my favorite points of discussion. I'll start out by saying that unless your "users" have only "PUBLIC" privs (and I mean not even db_DataReader privs) and you can't run xp_CmdShell in a stored proc without users being able to execute xp_CmdShell directly, then you may want to reexamine just how "locked down" you think things actually are.
Isn't shew saying that xp_CmdShell is unavailable or have I misunderstood this? He says that it along with "a host of other features is not allowed".
Regards,
Gaz
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
Yes, xp_cmdshell is unavailable, along with a host of other SQL Server features. This is the most locked down environment in which I have ever worked. Active Directory as well is locked down so tight that it squeeks when we install SQL Server. LOL
-
Gary Varga (8/18/2011)
Jeff Moden (8/17/2011)
shew (8/17/2011)
We are a "locked down" hosting facility (xp_commandshell as well as a host of other features is not allowed),Heh... xp_CmdShell. 🙂 One of my favorite points of discussion. I'll start out by saying that unless your "users" have only "PUBLIC" privs (and I mean not even db_DataReader privs) and you can't run xp_CmdShell in a stored proc without users being able to execute xp_CmdShell directly, then you may want to reexamine just how "locked down" you think things actually are.
Isn't shew saying that xp_CmdShell is unavailable or have I misunderstood this? He says that it along with "a host of other features is not allowed".
Regards,
Gaz
My apologies, Gary... I didn't state it clearly enough. It actually doesn't matter if xp_CmdShell is available or not... my point was that people who advertise a tightly "locked down" system frequently haven't locked it down as tightly as they may think. The only reason I brought xp_Cmdshell into the picture is because one of my measures of a secure system is one where users can execute stored procedures that contain calls to xp_CmdShell but the users, themselves, cannot execute xp_CmdShell nor even see any of the tables addressed by the stored procedure. 🙂
--Jeff Moden
RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.Change is inevitable... Change for the better is not.
Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally) -
No worries Jeff. I just wanted a little clarity for I am a developer of very little brain!!!
I only wish I understood more about the lack of security inherent in many designs but then again that is why I come here.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
-
Just for those who would like to change $pshome : you can do it here :
with regedit
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PSConfigurationProviders\Microsoft.PowerShell]
"ApplicationBase"="c:\\Windows\\System32\\WindowsPowerShell\\v1.0"
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply