cancel
Showing results for 
Search instead for 
Did you mean: 

TEMP Folder Security Test

Hi,

On my EV 10.4 CHF3 server I'm running SymHelp before upgrading to EV11.0.1 and keep getting an error for "TEMP Folder Security Test" in the Enterprise Vault 11.0.1 requirements.

The full text is:

Error    TEMP Folder Security Test
Error    TEMP folder 'H:\AppData\Local\Temp\' does not satisfy security requirements. See the 'Installing and Configuring' manual for details of the TEMP folder security requirements.

The folder only has SYSTEM and (Local) Administrators with full control. There are no inherited permissions.

I have moved TEMP on this particular server and have other servers where TEMP is located in the default and get the same reported.

I have gone through https://support.symantec.com/en_US/article.HOWTO108117.html and https://support.symantec.com/en_US/article.TECH224726.html and while I'm confident to add either of the Registry entries to work-around this I'd rather try and understand the problem.

Any help is greatly appreciated.

2 Solutions

Accepted Solutions
Accepted Solution!

I have tested all sorts of

I have tested all sorts of settings and configurations in my lab (10.0.4 and running the SymHelp checks in relation to upgrading to 11.0.1) in relation to this and the outcome is below:-

 

I have had the below configurations:-

  1. System and Local Administrators

  2. System, Local Admins and VSA

  3. System and VSA

  4. System only

  5. Local Admins only (ensuring the VSA was a direct member of the Local Admins group and not just a member of a nested group)

  6. VSA only

All of the above have failed the security tests and thrown the same error message, I have tried this on several locations as well, system drive and seperate drive.

 

I then had a 11.0.1 lab and ensured all was running as expected, EV working as expected.

Ran SymHelp, same error message again, due to all of the above I strongly believe it to be a bug in the SymHelp checks and have forwarded the concern onto the relevant team to look into and double check/correct for a future SymHelp release.

 

Due to the above, personally, I would ignore it for now as I honestly do not believe there to be any cause for concern.

View solution in original post

Accepted Solution!

FYI I worked this through

FYI

I worked this through with support and adding the "TempFolderExceptions" with my VSA added stopped SymHelp reporting the error. The folder still has the correct permissions as above.

Additionally I completed the upgrade from 10.0.4 to 11.0.1 without issue.

So there appears to be something wrong with the SymHelp check as the VSA is a member of the Local Administrators group which should "pass" as per TECH224726.

Thanks everyone for the assistance.

View solution in original post

8 Replies

Hi EC, I've had the same. It

Hi EC,

I've had the same. It turned out that you not only need to look at the folder permissions, but also at the disk (in storage admin) for permissions.

I found that there were some additional groups on the disk it self, which were causing this. I've implemented the registry keys to 'fix' it.

Regards. Gertjan

Thanks Gertjan, I'm not sure

Thanks Gertjan,

I'm not sure I understand where you are looking, can you please expand?

I'm WS 2008 R2 and checking in Disk Management, I open the properties of the disk, security tab and see the root permissions, H:\, they are the same as the sub-folder and only include authorised accounts.

 

Hi, In (Server Manager,

Hi,

In (Server Manager, Storage), Disk Management, I have on the disk with the TMP location for the VSA listed:

Authenticated Users, SYSTEM, Administrators and Users.

On the folder itself, I have SYSTEM, Vault Service Account and Administrators,

 

As far as I could determine from the description Symantec gives this should be good to go. I kept getting these errors too, hence me applying the regkey.

Regards. Gertjan
Accepted Solution!

I have tested all sorts of

I have tested all sorts of settings and configurations in my lab (10.0.4 and running the SymHelp checks in relation to upgrading to 11.0.1) in relation to this and the outcome is below:-

 

I have had the below configurations:-

  1. System and Local Administrators

  2. System, Local Admins and VSA

  3. System and VSA

  4. System only

  5. Local Admins only (ensuring the VSA was a direct member of the Local Admins group and not just a member of a nested group)

  6. VSA only

All of the above have failed the security tests and thrown the same error message, I have tried this on several locations as well, system drive and seperate drive.

 

I then had a 11.0.1 lab and ensured all was running as expected, EV working as expected.

Ran SymHelp, same error message again, due to all of the above I strongly believe it to be a bug in the SymHelp checks and have forwarded the concern onto the relevant team to look into and double check/correct for a future SymHelp release.

 

Due to the above, personally, I would ignore it for now as I honestly do not believe there to be any cause for concern.

View solution in original post

That's good info, thanks

That's good info, thanks Ben.

You will then have to set the registry key before upgrading, otherwise that will not function. due to the security failure, the upgrade will halt.

Regards. Gertjan

Thanks Ben, glad it's not

Thanks Ben, glad it's not only me.

I'll keep "SkipTempFolderCheck" in my back pocket in case it's needed during/after the upgrade to 11.0.1.

I logged a ticket when Gertjan first replied, I'll post any response I get.

Accepted Solution!

FYI I worked this through

FYI

I worked this through with support and adding the "TempFolderExceptions" with my VSA added stopped SymHelp reporting the error. The folder still has the correct permissions as above.

Additionally I completed the upgrade from 10.0.4 to 11.0.1 without issue.

So there appears to be something wrong with the SymHelp check as the VSA is a member of the Local Administrators group which should "pass" as per TECH224726.

Thanks everyone for the assistance.

View solution in original post

Thanks for the update EC,

Thanks for the update EC, Symhelp is still in the early stages and requires a few nips and tucks here and there, espcially as it spams several of our products in one package.

 

The relevant teams are aware of it and will be working on correcting the issue for a future release.