Windows Services utilize their own Windows sessions and security context, isolating them from other processes and users working on the same server. Although Windows Services has no user interface, there is an administrator function to start, pause, restart, and realize the necessary configurations. SharePoint also has an infrastructure to operate this type of process in the form of "SharePoint Timed Jobs." Jobs perform actions at predefined intervals (in minutes) or during an allocated period of time (hour, day, week, month, or year). Among other functions, SharePoint utilizes Timed Jobs for installing Solutions, indexing, and with its search engine. One disadvantage of Timed Jobs is that the time structure is organized in defined slots (hour, days, and so forth). If a task requires a specified time configuration, for example, to run each second Saturday of the month, the Jobs framework falls short. Another drawback is that Timed Jobs are SharePoint-dependent; imagine, for instance, a system that needs to track the availability of the Portal. In this scenario, if SharePoint is down, the Jobs infrastructurealso is unavailable for use. A Windows Service that runs autonomously is able to check the accessibility every few minutes, and if necessary, create a log.