Showing posts with label System Center. Show all posts
Showing posts with label System Center. Show all posts

4/06/2011

Switch from Local System to User context

Sometimes there’s a need to switch from Local System context to the current logged on User.
The following article describes how to achieve this.

In short words the following happens:
1. Something is executed in local system context
2. At the end a EventLog entry is written
3. A Scheduled Tasks gets trigged by the created EventLog entry
4. The Scheduled Tasks which is running in User context executes another script

One example is e.g. to inform Users about an Installation which was executed from the Local System Account. The Application Deployment process executes the CreateEventToInform.vbs Script at the end of the installation to create the EventLog entry for informing the User

CreateEventToInform.vbs
Dim objShell : Set objShell = CreateObject("WScript.Shell")
Dim strMessage : strMessage = "Dear User this is a message from your local system"
objShell.LogEvent(4, strMessage)


InformUser.vbs
Dim strMessage
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & "."
& "\root\cimv2")
Set colLoggedEvents = objWMIService.ExecQuery("Select * from Win32_NTLogEvent Where Logfile = 'Application' and SourceName='WSH' and EventCode=4 and Type='Information'")

For Each objEvent In colLoggedEvents
strMessage = objEvent.Message
Exit For
Next

MsgBox(strMessage, vbInformation + vbOKOnly, "Your Company")


It could also be used as an immediately executed “ActiveSetup” for the current logged User. The Application Deployment process executes the CreateEventToExecute.vbs Script at the end of the installation to create the EventLog entry for performing a Active Setup for the current User

CreateEventToExecute.vbs
Dim objShell : Set objShell = CreateObject("WScript.Shell")
Dim strCommandLine : strCommandLine = "msiexex /fup "
objShell.LogEvent(4, strCommandLine)


ExecuteUserPart.vbs
Dim objShell : Set objShell = CreateObject("Wscript.Shell")
Dim strCommandLine
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & "." & "\root\cimv2")
Set colLoggedEvents = objWMIService.ExecQuery("Select * from Win32_NTLogEvent Where Logfile = 'Application' and SourceName='WSH' and EventCode=4 and Type='Information'")

For Each objEvent In colLoggedEvents
strCommandLine = objEvent.Message
Exit For
Next

objShell.Run(strCommandLine, 1, False)


To make the whole think work we have to create a trigger which reacts to the EventLog Entry which was created. Create a Scheduled Tasks which is executed in the User context as listed below for this

Note: You can deploy scheduled tasks to many computer automatically e.g. with Group Policies

Now as soon as the EventID is written the Scheduled Tasks executes the below listed command



Further thoughts:
You could create a whole Application which is written variable so that you can perform different actions in User context. To achieve this easily you could tag the EventLog Message with specific keywords. Later the Application parses the EventLog Message and you can react on this. So you can use it for different scenarios. Example:

WriteEventLog.vbs
Dim objShell : Set objShell = CreateObject("WScript.Shell")
Dim strMessage : strMessage = "[Inform]Dear User now there's happening something" &vbNewLine &"[Execute]msiexex /fup "
objShell.LogEvent 4, strMessage


PerformInUserContext.vbs
Dim objShell : objShell = CreateObject("Wscript.Shell")
Dim strMessage, arrEventEntry
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & "." & "\root\cimv2")
Set colLoggedEvents = objWMIService.ExecQuery("Select * from Win32_NTLogEvent Where Logfile = 'Application' and SourceName='WSH' and EventCode=4 and Type='Information'")

For Each objEvent In colLoggedEvents
strMessage = objEvent.Message
Exit For
Next

arrEventEntry = Split(strMessage, vbNewLine)

For Each strLine In arrEventEntry
If InStr(strLine, "[Inform]") Then
MsgBox(Replace(strLine, "[Inform]", ""))
ElseIf InStr(strLine, "[Execute]") Then
objShell.Run(Replace(strLine, "[Execute]", ""), 1, False)
End If
Next

10/01/2009

ConfigMgr SQL Backup Service on the wrong volume - Workaround

Your going to install a ConfigMgr 2007 with the database stored on a remote SQL Cluster server. During the installation of the database there will be installed a ConfigMgr database backup service on both cluster nodes. This service is named SMS SITE SQL BACKUP. By default during this installation the volume with most free space is used to store the service. This can cause various problems on a cluster. E.g. Systemstate backup fails, as a service running on a shared volume cannot be accessed.
To bypass this behavior there should be created a file named NO_SMS_ON_DRIVE.SMS on the root of each volume of the cluster which shell not be the volume for the service installation.
If the service installation is already done on a shared volume, it's getting difficult.
There are various opinions how this problem could be solved...
For example one is to move the Configmgr database to another server, create the file on the volume and move it back to the server, so that the installation is running once more and the volumes with the file will be skipped. Another option which is discussed is to do a site repair.
Then i've found the following post from Razmus on Microsoft forums. Then i did the following:

Note: X=Wrong drive letter, Servername=Your MgmtPoint

1. I moved the service folder X:\SMS_Servername from the wrong volume to the desired one.
2. In the Management Points registry go to the path HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_SITE_COMPONENT_MANAGER\Multisite Component Servers. Below this key there are listed two subkeys named as both cluster nodes. On each of this key there is a value named Installation Directory. Here should be the driveletter also changed.
3. In the registry of each cluster node go to the path HKLM\SYSTEM\CurrentControlSet\Services\SMS_SITE_SQL_BACKUP_Servername and change the value ImagePath to the new driveletter also
After restarting the service SMS_SITE_SQL_BACKUP_Servername on the cluster node the new execution path should be changed to the new volume. Afterwards i removed the service folder from the wrong volume to make sure that the service is really running on the selected volume. This seems to work. The only problem is still have is, that the folder is still created on the wrong volume when the service is restarted. But it only contains the logfile. I can live with this behaviour, as the executable is running on the correct one.