John McFadyen's profileJohn McFadyens Windows I...PhotosBlogGuestbookMore ![]() | Help |
|
|
October 14 Sequencing PART IIHi all, its been a while since my last post as I have been pretty busy with RL lately. A few people have been asking why I haven't been posting. Although there are many reasons I won't bore you with the details. Anyway this latest topic is something that so many people misunderstand, misuse, or simply don't care about. Which in my mind is all the more reason why I should write about it. This is heavily related to my first post on installation sequences then you should probably have a quick look at that first. I left out some important bits of information I just assumed everyone knew. Interestingly enough the more packagers I have spoken to lately the more I realise the complete lack of understanding that is out there. Even some of the major players and training institutions are getting this wrong but I won't go into who, where and why you can work that out for yourselves. (I hope I don't goof the explanation and do the same). I have updated the last diagram I drew to try to clarify these next explanations. So from the diagram above its a little difficult to see how this relates back to the tables. So bare with me while I try to explain it all. As we already know about standard installation conditions there are two tables which are processed. These tables are InstallUISequence and InstallExecuteSequence table. From the diagram above the green sections represented as the Acquisition phase consist of those two tables. During the processing of these two tables the installer service is Acquiring information about what actions need to be performed during installation. (hence the name). The execution phase on the right shown in the purple has two sub-phases which are known as Deferred and Commit/Rollback. This is explained in more detail in my previous blog Installation Sequences. What I am going to cover in this blog is the smaller items at the bottom of this picture. These represent the actual Windows Installer Service and how things are processed during the Acquisition and Execution Phases. There are two processes CLIENT and SERVER. The CLIENT process is protected and has limited access to the Windows Installer database (MSI) and the underlying Operating System. The CLIENT portion also runs programs which are only in memory for the duration of the task and then they are terminated. The SERVER process usually consists of processes which don't terminate, one of the most important of those processes is the actual Windows Installer Service. The SERVER process needs full access to the Operating System to allow installation of the application and its resources. For this reason a portion of the installation needs to be elevated for the duration of the requirements needed to install the application. In order to optimise security and limit the time the installation has full rights the Execution phase was born. I often hear many people say why does this need to be so difficult, the answer to that is that to successfully install on the myriad of platforms and user rights coupled with locked down environments the sequencing need to be complex to accommodate all of these requirements whilst maintaining optimum security. So lets run through an installation again this time taking notice of the processes and how this affects the installation. So lets assume we double click on an MSI running the standard installation. A CLIENT and SERVER process is launched. We first start to process the actions in the InstallUISequence, those actions are passed through to the CLIENT process. This means that during UI phases we have limited access to the underlying operating system. During this CLIENT side processing we do not have full access to the windows installer database. We then start to process the InstallExecuteSequence during this part of the acquisition phase we have access to both the CLIENT and SERVER processes (this can be verified through check an installer log and looking for the (c) and (s) entries in the log). As such we have both read / write access to Windows Installer MSI however we still only have limited access to the underlying operating system. So according to my diagram above the yellow section has both access to the pink and purple section in the upper row of the process section of that diagram. When we reach the execution phase (also commonly referred to as Deferred) a very important thing happens. Two additional processes are launched which are run in User / System context (or service account context). During the deferred phase actions were written to the installation script by the acquisition phase are then passed to one of the two newly created services. Because these two processes are launched here this is how we gain full access and elevation to the underlying operating system. Now the most important part to understand here is this.
This is a very very important and often overlooked distinction. Because the two additional processes are launched at the start of the deferred phase it is the only location where we have true elevation capabilities and as such it is also the reason during this phase is the only place we have the capability to install an application on a locked down environment. It is also the reason why you cannot access the session object during the deferred phase. This is why you hear so many people say when you modify the system you must use a deferred CA. Because the deferred phase is the only phase that has access to the Windows Installer Service accounts elevated context. To summarise all of this
I was going to cover Custom Actions and there placement within these sequences but I think I will leave that for the next post as its getting late where I am. Please feel free to ask any questions you have on this or post comments as this will inspire me to do this more often. |
|
|