Jump to content
Welcome to our new Citrix community!

Storefront cannot be upgraded because the following folders are in use


Jacob Dixon1709152413

Recommended Posts

I can't seem to get Storefront to upgrade when using the 7.15 CU1 LTSR media. It constantly says "StoreFront cannot be upgrading because the following folders are in use by another program. Close the program and try again." "C:\inetpub\wwwroot\Citrix\Web"

 

The problem is the folder isn't in use, I can rename the folder, I stopped all services including IIS, and I still constantly get this prompt.

Link to comment
Share on other sites

28 minutes ago, Rhonda Rowland1709152125 said:

Did you see the other recommendations in this article:  https://support.citrix.com/article/CTX220464

Stop resource pool to OnDemand...

 

Yes I actually changed them to all OnDemand. But also disabling the WWW service means they wouldn't be running anyways and I tried that as well.

Link to comment
Share on other sites

19 hours ago, Manbinder Pal Singh said:

You should try the newer version not the same version. Do share logs though before you do that,

 

Attached is the logs. Error in event viewer continues to state:

 

Timestamp: 4/15/2018 10:02:45 AM
Category:Warning, WinError
Message:[MessageBox] CXMI silent message box: 
    Title: Citrix StoreFront Setup
    Message: StoreFront cannot be upgraded because the following folders are in use by another program. Close the program and try again.

C:\inetpub\wwwroot\Citrix\Web
    Response: 

 

I think this is a bug because nothing is using that folder. I've checked open files, renamed that directory (if something was open I couldn't rename the entire root directory).

XenDesktopUpgrade.txt

Link to comment
Share on other sites

This log is for XAXD metainstaller. I would like to get SF logs which should be under C:\windows\temp\storefront.
This is not a bug as definitely there are processes holding lock on the folder. You can run handle.exe from the sysinternal tools to find which processes are holding lock on this folder and then stop those processes/services ( telemetry  service , IIS , Citrix storefront * services are common ones to hold locks ).
SF can certainly do better if possible to handle this or at least provide detail on which process/service is holding locks. We try to do that as much as can be done.
I will follow up and add this improvement item to our list though.
Hope this helps.
 

Link to comment
Share on other sites

21 minutes ago, Manbinder Pal Singh said:

This log is for XAXD metainstaller. I would like to get SF logs which should be under C:\windows\temp\storefront.
This is not a bug as definitely there are processes holding lock on the folder. You can run handle.exe from the sysinternal tools to find which processes are holding lock on this folder and then stop those processes/services ( telemetry  service , IIS , Citrix storefront * services are common ones to hold locks ).
SF can certainly do better if possible to handle this or at least provide detail on which process/service is holding locks. We try to do that as much as can be done.
I will follow up and add this improvement item to our list though.
Hope this helps.
 

 

I discovered it was actually the Configuration folder and Authentication for Storefront that had a file locked due to the application pool in IIS. So while this may not have been a bug, the error message specially stated c:\inetpub\wwwroot\Citrix\Web when in fact it was c:\inetpub\wwwroot\Citrix\Authentication and c:\inetpub\wwwroot\Citrix\Configuration

 

On my other server it was the Telemetry service causing it not to upgrade. Yeah, Citrix can do better.

Link to comment
Share on other sites

  • 3 months later...
On 4/17/2018 at 0:08 AM, Jacob Dixon1709152413 said:

 

I discovered it was actually the Configuration folder and Authentication for Storefront that had a file locked due to the application pool in IIS. So while this may not have been a bug, the error message specially stated c:\inetpub\wwwroot\Citrix\Web when in fact it was c:\inetpub\wwwroot\Citrix\Authentication and c:\inetpub\wwwroot\Citrix\Configuration

 

On my other server it was the Telemetry service causing it not to upgrade. Yeah, Citrix can do better.

what exactly was done here on these two folders? c:\inetpub\wwwroot\Citrix\Authentication and c:\inetpub\wwwroot\Citrix\Configuration ??

i'm stuck with the same issue

Link to comment
Share on other sites

2 hours ago, Jacob Dixon1709152413 said:

I believe I stopped the correct application pools and then did the upgrade. The problem was the installer was complaining about the wrong folder which led me down the wrong path. Once I discovered it was actually the other directory, I stopped that application pool that corresponded with that directory.

jdixon226 appreciate your Response:) I'd stopped the entire IIS service, and have checked that the app pools are stopped. still getting the error. Has been Really really annoying.

thing is i cant let go of the LTSR path, so cannot use 3.14 or 3.15..

Link to comment
Share on other sites

  • 9 months later...

the process to debug is best used by using process explorer to check what has the file handles open

 

downloaded Process explorer from,

                https://download.sysinternals.com/files/ProcessExplorer.zip

 

  1. Open Process Explorer, running as administrator.
  2. Enter the keyboard shortcut Ctrl+F. Altenatively, click the “Find” menu and select “Find a Handle or DLL”.
  3. A search dialog box will open.
  4. Type in the name of the locked file or other file of interest. In this case I entered “C:\inetpub\wwwroot\Citrix\<folder in use>"
  5. Click the button “Search”, A list will be generated. There may be a number of entries.

 

In this case, explorer.exe was listed as having two handles open to the folder.

 

To resolve, I used process explorer to terminate explorer.exe.

I used run option to launch the installation assistant (from the installation media) and the upgrade was performed without issue.

 

I am including in case this may be of use to someone else, it might just be the operating system leaking a file handle (as in my case).

Be sure to review the log files (inside windows\temp\storefront) for the specific file or folder in use preventing the install.

Link to comment
Share on other sites

  • 1 year later...
On 6/13/2019 at 3:18 PM, Adam Walker said:

the process to debug is best used by using process explorer to check what has the file handles open

 

downloaded Process explorer from,

                https://download.sysinternals.com/files/ProcessExplorer.zip

 

  1. Open Process Explorer, running as administrator.
  2. Enter the keyboard shortcut Ctrl+F. Altenatively, click the “Find” menu and select “Find a Handle or DLL”.
  3. A search dialog box will open.
  4. Type in the name of the locked file or other file of interest. In this case I entered “C:\inetpub\wwwroot\Citrix\<folder in use>"
  5. Click the button “Search”, A list will be generated. There may be a number of entries.

 

In this case, explorer.exe was listed as having two handles open to the folder.

 

To resolve, I used process explorer to terminate explorer.exe.

I used run option to launch the installation assistant (from the installation media) and the upgrade was performed without issue.

 

I am including in case this may be of use to someone else, it might just be the operating system leaking a file handle (as in my case).

Be sure to review the log files (inside windows\temp\storefront) for the specific file or folder in use preventing the install.

 

Thanks for this.  This is a life saver. I never would have thought something so basic was sabotaging the install. 

I ended up copying the ISO (1912) to the server to path out the install for running the Task.

 

I found that I also had 2 instances of Explorer locking up the c:\inetpub.....\Custom folder. 

 

In my case I found killing explorer, and just simply trying the install again wouldn't work. Your method of keeping Explorer dead had to be done or Explorer would grab the folder again. 

 

It's disappointing that this isn't fixed after all this time. Thanks for posting the work around. 

 

As a side note I'm doing an upgrade of our Citrix environment from 7.15 to 1912 CU1 LTSR and it's not pretty. Each step has been a grind thus far but I'm only about a third of the way there. I think this is why so many environments choose not to upgrade  and risk using outdated / unsupported software. 

Link to comment
Share on other sites

  • 2 years later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...