Virtualization

Create a shortcut to the file or if they need explorer like functionality then you need to use a shell replacement since explorer is pretty much an operating system component. I suggest a43 but there are a few out there.

I assume that you are using app-v.

If ther user is an administrator on the machine they should be able to access the Q: drive via the adminsitrative share ("\\<Machine name>\q$"). This is what I use when looking inside the Q drive on our machines.

Depending on the situation there could be several other ways around this problem:
Edit the virtualised application to point the log creation directory elsewhere. (probably a registry or file somewhere)
Create a shortcut to the log file. user can then open it read and save elsewhere
Create a shortcut to a custom application which copies the log
Create a post shutdown script in the OSD file to open or copy the log.

Hope that helps

Hi, thanks for the help.

So I created a shortcut to: \\127.0.0.1\q$ and \\"PC-Name"\q$
both show me the Q drive folder associated with my application.

But.....

I can only access it while the application is running?

If that is "normal" I guess I can live with that....as previously suggested, I could copy the LOG file to another location.

But.....and this is a big one.....

When I browse to where my LOG file is located, I see a log file from when I launched my application during the virtualization packaging last month, but I don't see a log from the current launch of the application or any of my previous launches since virtualized.

Log file path I browse to: \\127.0.0.1\Q$\AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\

The application creates a new log file with the current date and a counter appended to the name of the LOG file, each time it is launched:
EnterpriseMonitor_04-12-11_01.LOG
EnterpriseMonitor_04-12-11_02.LOG
EnterpriseMonitor_04-12-11_03.LOG


I ran PROCESS MONITOR
and I found references that look like they created the LOG file and it is in the Q drive directory but I see no evidence of it on my Q drive only "old" ones from the date I packaged the application.


11:30:45.5853735 AM EnterpriseMonitor.exe 4224 QueryNameInformationFile Q:\AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\EnterpriseMonitor_04-12-11_03.LOG
SUCCESS Name: \AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\EnterpriseMonitor_04-12-11_03.LOG

11:30:45.5854707 AM EnterpriseMonitor.exe 4224 QueryStandardInformationFile Q:\AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\EnterpriseMonitor_04-12-11_03.LOG
SUCCESS AllocationSize: 0, EndOfFile: 0, NumberOfLinks: 1, DeletePending: False, Directory: False

11:30:45.5855781 AM EnterpriseMonitor.exe 4224 WriteFile Q:\AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\EnterpriseMonitor_04-12-11_03.LOG
SUCCESS Offset: 0, Length: 124

11:30:45.5856920 AM EnterpriseMonitor.exe 4224 WriteFile C:\Documents and Settings\joel.sternin\Local Settings\Application Data\SoftGrid Client\ASPMGPS2.001-1C6F1B6C-59D6-467C\UsrVol_sftfs_v1.tmp
SUCCESS Offset: 4,399,104, Length: 4,096, I/O Flags: Synchronous

11:30:45.5857913 AM EnterpriseMonitor.exe 4224 CloseFile Q:\AspMGpS2.001\Aspect Software\Unified IP Client\Logs\epro\EnterpriseMonitor\Initialize\EnterpriseMonitor_04-12-11_03.LOG
SUCCESS



Any suggestions?

Thanks

-Joel

I guess I will try to repackage and point the logs to the "C" drive to see if that helps because even though Process Monitor indicates (as best as I can tell) that the log files are being created, I can't find them on "Q".

Appologies for the delayed reply.

Bearing in mind that we have an odd setup of app-v (app-v in SCCM) so my experiences may be slightly different to a standard app-v setup.

Yes it is normal for the q: drive files within the 8:3 folder to only be accessible via the admin share when the software is running.


After reading your post this morning i have had a look at one of my app-v apps and also noticed that if i create something on the q: drive it appears on the share when the current application is running however if i shutdown the app and re-launch the file is not visible via the share. After re-launching the application the file was not visible via the \\127.0.0.1\q$ however was still visible from within the application (File-->open).
I believe this is due to the profile file (C:\Documents and Settings\<username>\Application Data\SoftGrid Client\{app-name}) which modifies the virtual environment on a per-user basis, therefore as the explorer process viewing the q$ is not in the virtual environment it cannot see the previously created files (although this is hitting the limit of my current app-v knowledge and is making an assumption). Thanks, this has given me a point for thought and I shall read up on it and investigate at some point in the future.

So appologies as it appears that in this situation using the q$ share is not a great way of accessing files created on the q: drive.


The other option for a solution depending on whether the user wants to keep the log files or not could also be to create a OSD shortcut to notepad and launch it within the same virtual environment. Then notepad would be able to see the log files created.


From what you have said if i was in your situation i would most likely:
Edit the package to remove the log files created at the time of sequencing
Create a script (prob .vbs) which copies *.log files from the initialise directory to another location (prob C:\temp)
Add the script to the applications OSD file launchig Post Shutdown and Within the Virtual environment

{<DEPENDENCY>
<SCRIPT TIMING="POST" EVENT="SHUTDOWN" WAIT="TRUE" PROTECT="TRUE">
<SCRIPTBODY>%SFT_MNT%\\<Path to script></SCRIPTBODY>
</SCRIPT>}

That way the files should persist on the c:\temp directory even when the software is not active.

dbloomfield's suggestion looks good

What will i do ?

1. create script vbs that copy "log files" to local system ( must see that normal user have permission to write to same folder)
2. run it in post shutdown .

Note: There can be different scenario like logs files are getting updated (we don't need to do much in script just overwrite the content of local system folder)
if it is appending then we may have to delete the present log file in local system folder then copy (this functionality need to be done in script).