Skip to main content

Symantec Installation Failure

We've been looking for alternatives to Trend Micro WFBS lately, and I thought I'd give Symantec Endpoint Protection another shot. I spent several hours fighting with the installation package and Symantec Support, but continually had issues with a VBS file that is supposed to run in the setup. A week and several pots of coffee later, I found the problem.

During the installation, Symantec executes iisconfig.vbs, a script designed to setup all of the IIS elements for the management portal. However, the installation rolls back and SEPM_INST.LOG showed the following "return value 3" message everytime.

SESM CA: Failure in IIsConfig.vbs script - See the Windows Event Viewer application log for the failure event.

I went through every article on Symantecs website concerning the issue with no luck. Symantec insisted this was an IIS problem, but even reinstalling IIS did not resolve it. Luckily the issue jumped out at me before it came down to a wipe and reload.

I ran Process Monitor while the install was running and noticed the following line:

MsiExec.exe IRP_MJ_CREATE C:\WINDOWS\system32\cscript.exe ACCESS DENIED Desired Access: Read Data/List Directory, Execute/Traverse, Read Attributes, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a NT AUTHORITY\SYSTEM

IRP_MJ_CREATE is the function used to open a file system object (or create a new one), so I looked at cscript.exe and sure enough, the SYSTEM account was set to deny all on the security permissions. I don't see this on any of my other 2003 servers, so I'm assuming it was a result of some hardening at one point in time before I inherited this client. As it turns out, the problem had nothing to do with IIS technically.

If anyone can tell me what sort of automated hardening (Security template perhaps?) causes this I would love to know so I can delve into other issues that may creep up on this server.


Popular posts from this blog

Outlook Credential Prompt When Opening Exchange 2013 Public Folder

After completing an Exchange 2007 > 2013 migration recently, I was left with one issue that was preventing us from stamping the project as a roaring success and moving on:

Outlook 2013 users were sometimes receiving a single pop-up prompt for credentials whenever they opened the Public Folder (we have only one). One. Single. Prompt.

Google was frustratingly unhelpful because searching for "outlook prompts for username and password when opening public folders" or something similar just resulted in a lot of folks who were always getting a pop-up that wouldn't go away. It was usually caused by an authentication failure of some sort.

However, we were in a different boat - Users got the prompt once when they first launchedOutlook and opened their public folders, but after entering it they could continue - authentication worked. Next time they logged in to their PC, it would happen again. Not a show stopper, but it definitely generated its share of support calls.

Repairing Mailbox Corruption in Exchange 2010

I recently got through recovering an SBS 2011 server after Active Directory face-planted in the middle of a workday. When I say recover, I mean I repeated the entire migration, using a cleaned up secondary DC - it was a fun weekend (expect another post about that experience). Although I thought we were in the clear, I got a call from the client about 24 hours after we had verified everything was working. He indicated that his iPhone had suddenly stopped receiving mail in the inbox (calendar, contacts, sent items were still fine) and throws up an error after spinning in circles for a few minutes that it "cannot connect to mail server".

SCEP Policy Update Troubleshooting

Because I'm a glutton for punishment, I recently started rolling out System Center Configuration Manager 2012 R2 SP1 and System Center Endpoint Protection across our VDI environment. There are always some considerations to be made in a pooled desktop / gold image type environment when loading software that uniquely identifies devices, but lucky for me SCCM/SCEP handled this just fine without any tweaking. However, there were some nuances to how SCEP policies are applied that caused some serious hair-pulling before I spotted the issues.