SQL Server 2008 database engine login "sa" failed for administrator user

Depending on what mode SQL Server was installed (Windows Authentication or Mixed Mode), you may have to do a few things. If you installed in mixed mode, you can log in as sa and add the administrator user as a Login under the Security section. Make sure you assign sysadmin role to the user, which can be found under Server Roles.

If Windows Authentication mode was chosen during install then there are a couple of things you can do, but I think the easiest is just to recreate the user "sa_new", login into SQL Server as that user, and follow the previous step to add the administrator user as a login.

UPDATE: If all else fails, you can run SQL Server in Single User Mode, which allows a single connection to the server, and enable/change the sa password. To do this you can:

1. Open the command prompt (Right-Click on and select "Run As Administrator")
2. From the command prompt type net stop MSSQLSERVER
3. Next type net start MSSQLSERVER /m
4. Open SQL Server Management Studio. Do not login, cancel the login dialog.
5. From the file Menu select New->Database engine query, and login (Make sure you use the host name and not localhost).
6. Execute the query ALTER LOGIN sa WITH PASSWORD = ''; to reset the password (if the sa is not enabled then type ALTER LOGIN sa ENABLE to do so)
7. Login with the sa user and add the Administrator user.

EDIT:
For step 6 you may have to do ALTER LOGIN sa WITH PASSWORD = '' UNLOCK;, because the sa account may be locked from too many login attempts.

Tested on Windows 7 Ultimate with SQL Server 2008 Standard. Hope this helps.

Managing EMET settings with Active Directory Group Policy

Q: Is it possible to centrally control the Microsoft Enhanced Mitigation Experience Toolkit (EMET) configuration settings through Group Policy?
A:Yes, EMET 3.0 supports the central configuration of EMET settings using Group Policy Object (GPO) settings. So, if you have EMET installed on some of your Windows systems in your Active Directory (AD) domain so that developers can test application compatibility when the Address Space Layout Randomization (ASLR) attack mitigation feature is enabled, for example, you can use Group Policy to control EMET settings.

Related: Q. What's the Enhanced Mitigation Experience Toolkit (EMET)?
When you install EMET, the EMET.admx and EMET.adml administrative template files are automatically installed to the <SystemDrive>\Program Files\EMET\Deployment\Group Policy Files folder. To effectively leverage these files from your GPOs, you must copy the .admx file to the <SystemDrive>\Windows\PolicyDefinitions file system folder and the .adml file to the <SystemDrive>\Windows\PolicyDefinitions\en-US folder. After moving the files, you can centrally configure system-wide and application-specific EMET attack mitigation settings from the \Computer Configuration\Administrative Template\Windows Components\EMET GPO container, as Figure 1 shows.

Figure 1: The Enhanced Mitigation Experience Toolkit (EMET) GPO settings

For example, to exempt the Google Chrome application from ASLR on all machines in your domain that have EMET installed, you can use the Application Settings GPO setting, as Figure 2 shows. To configure this option, open the setting, set it to Enabled, then click the Show button at the bottom. Finally, enter "chrome.exe -MandatoryASLR" in the Show Contents screen to add the domain-wide ASLR opt out exception for chrome.exe.

Figure 2: Defining an application exception for chrome.exe by using EMET GPO settings

After you've centrally configured EMET GPO settings, the GPO client-side engine writes them to the local system registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EMET. But this step alone isn't sufficient to apply the EMET settings automatically on the level of the EMET client-side logic. To make them effective in EMET, you must run the following EMET_Conf.exe command during system startup or user logon:

 

EMET_Conf --refresh

(Note the use of a double dash before refresh.) Also keep in mind that the EMET settings you configure through Group Policy take precedence over the settings an administrator or user configures locally by using the EMET GUI or command-line tools.

Setting file & directory permissions in Windows 2008/7 from command line

Fig.1

Let's assume you are responsible for managing permissions on a file server with a folder structure resembling the one in Figure 1. There you'll see a root folder named Shared that contains the Finance and Marketing subfolders, which contains additional subfolders. You'll also notice that the folders are configured so that increasingly smaller groups of people can access lower-level shares. For example, Finance Users can read information in the Budget folder, but only Budget Users can write to it. A restricted folder is also present at the bottom that no one should be able to see except those with Restricted access. This is a common structure on many file servers today.

You can use icacls to set permissions like those in Figure 1, but exactly how to do this is not immediately obvious. To set the indicated permissions for just the Metrics folder, you would use the following syntax:

icacls C:\Shared\Finance\Metrics /grant:r "Finance Users":(OI)(CI)M /grant:r 

"Metrics Users":(OI)(CI)M

Unfortunately, with great power comes great complexity. As you can see, icacls' syntax can be quite impenetrable, at least until you understand how Windows permissions work. Remember that an individual permission can be applied to a single folder object or to the object plus its subfolders and files. This is the concept of inheritance. When you apply the simple Modify permission within the explorer GUI to a folder, as in Figure 2, you are actually applying it to that folder as well as all subfolders and files.

 

Fig.2

Figure 2 Applying Simple Permissions Automatically Sets Inheritance for Subfolders and Files.

In the command line above, you can see that for each group, the M for modify comes after (OI)(CI), which stand for "object inherit" and "container inherit" respectively. Both of these are necessary if you want icacls to apply the simple modify permission. You'll also notice that ":r" is added after the /grant switch. This modifier instructs icacls to clear any directly applied permissions on the object before adding the permissions you set in the command line.

Complex, yes, but Windows permissions are complex. Keep in mind that the end goal—reusable commands—will actually make things much simpler.

To continue the example, let's walk through the entire set of icacls command lines you would use to reset and correctly apply the stated permissions to the Finance folder structure as well as its root:

Icacls C:\Shared /inheritance:r /grant:r "Domain Users":(OI)(CI)R /grant:r 
"File Admins":(OI)(CI)F

Icacls C:\Shared\Finance /inheritance:r /grant:r "Finance Users":(OI)(CI)R

/grant:r "File Admins":(OI)(CI)F

Icacls C:\Shared\Finance\Budget /grant:r "Budget Users":(OI)(CI)M
Icacls C:\Shared\Finance\Metrics /grant:r "Metrics Users":(OI)(CI)M

The first line actually accomplishes two tasks. It starts with the "/inheritance:r" switch to completely remove all inherited permissions from the folder above so that the Shared folder doesn't inherit. This breaks the Shared folder's inheritance from the folder immediately above it. Once this is done, the Read permission for is set for Domain Users and the Full Control permission for File Admins.

Because we don't want Domain Users to have access to the Finance folder at all, line two breaks and clears the permissions inheritance once again. It then applies the Full Control permission to File Admins and the Read permission to Finance Users.

With lines three and four, we don't want to break the permissions inheritance because both the File Admins and the Finance Users groups should have the same access to these subfolders. In these two lines, we are simply granting another permission—in addition to the existing inherited permissions—so that the Budget Users and Metrics Users can write to these folders.

Setting permissions for the Marketing folder is slightly different. We use the same permissions flow for the Product folder as we did for the subfolders under Finance, but the Restricted folder will be treated a bit differently. Let's suppose that folder contains highly secret documents that should be seen by only a very few individuals. Your first thought may be, "A-ha! Here, I'll use the Deny permissions to prevent the wrong users from accessing this folder!"

But keep in mind that the Deny permissions is actually far too powerful a setting for most situations as it automatically overrides every other permission. Therefore, adding the Deny permission to the Marketing Users group for this folder means that any Restricted users who are also Marketing users would be shut out. A more appropriate solution here is to break the inheritance again and simply eliminate all permissions for the Marketing Users group. Thus, the three icacls command lines required to set the permissions for this structure are

Icacls C:\Shared\Marketing /inheritance:r /grant:r "Finance Users":(OI)(CI)R

/grant:r "File Admins":(OI)(CI)F

Icacls C:\Shared\Marketing\Product /grant:r "Product Users":(OI)(CI)M

Icacls C:\Shared\Marketing\Restricted /inheritance:r /grant:r "File Admins":(OI)

(CI)F /grant:r "Restricted Users":(OI)(CI)M

Event ID 5059 — IIS Application Pool Availability

Applies To: Windows Server 2008 R2 SharePoint 2010
Web sites and Web applications depend on the availability of Internet Information Services (IIS) application pools. IIS application pools in turn depend on the Windows Process Activation Service (WAS). If WAS is not running or errors occur during the startup or shutdown of an application pool, Web sites and Web applications may not be available.

Event Details

Product:	Internet Information Services
ID:	5059
Source:	Microsoft-Windows-WAS
Version:	7.0
Symbolic Name:	WAS_EVENT_RAPID_FAIL_PROTECTION_REGARDLESS
Message:	Application pool %1 has been disabled. Windows Process Activation Service (WAS) encountered a failure when it started a worker process to serve the application pool.

In our environment we harden all of our Servers and upon the hardening procedures we noticed that the IIS Application Pool wouldn't start. After a couple restarts and undoing some of the lock downs we had to make an exception to one of the lock down procedures.

Verify

In the Active Directory Group Policy for our SharePoint Servers we had to add the "Sharepoint Farm account" to the "Log on as Batch Job" entry. Per our lock down this setting requires us to leave it blank, with no entry. If the SharePoint Farm account is part of the Administrators group then the Administrators group would need to be added to that entry instead. Once we did that we rebooted the SharePoint servers all the sites and Central Administrator console came up fine.