cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about the Community Ranking System, a fun gamification element of the PTC Community. X

Windows Start menu issue

davehaigh
11-Garnet

Windows Start menu issue

I'm trying to solve a problem with my install script.

Instead of cluttering the user's desktop with shortcuts I move a whole folder structure of shortcuts to the windows start menu folder.


1. rem ** Move shortcuts to the Windows Start menu

2. echo d|xcopy "C:\ptc\startup_scripts_3\Creo 3 Software" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Creo 3 Software" /y /r /s /e

My issue is most of the time it doesn't do it.

If I open up a command shell the command works.

Here's what I know about Windows 7:


1. In Windows 7 elevated and non-elevated accounts are not linked, so they don't share the same drive mappings. Consequently a script you start using "Run as administrator", will not see mapped drives.

2. Also an account in the Administrators group still runs everything not explicitly elevated as a limited user. So if you open a command shell while logged in as an admin, it will not run with elevated permission.

3. The only user that has full amin rights is the Administrator account, which runs everything elevated. Normally this account is disabled.


This means that if you use "run as admin" to start a batch file or open a command shell, that process will not be able to access any network shares. But, if you just open a command shell, or run a batch file, that process will not have elevated privileges.

The Windows start menu is here:
"C:\ProgramData\Microsoft\Windows\Start Menu\Programs\"

Surprisingly, moving files into this location requires elevated permissions. So, if you don't run the batch file using "Run as administrator", the script will not place the required files in the start menu.

My issue is the Run as Administrator trick was working... now it's not.
If I run the command interactively in a command shell it works. If I run it as a batch file it doesn't work even if I use "Run as Administrator"

Anyone know how to make this work consistantly? Or, how to open up the permissions to the start menu folder so a normal human can put files in there using a batch file?

David Haigh
Phone: 925-424-3931
Fax: 925-423-7496
Lawrence Livermore National Lab
7000 East Ave, L-362
Livermore, CA 94550


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
6 REPLIES 6

Can you change permissions for the start menu? We have given "users' full control access to the C:\ProgramData\Microsoft\Windows\Start Menu\Programs folder, which seems to work fine:

[cid:image001.png@01D03BA8.50EE3F80]

--
--
Doug Schaefer | Experienced Mechanical Design Engineer
LinkedIn
tmcnaney
12-Amethyst
(To:davehaigh)

What about creating a junction or symbolic link between those two folders?


Creating this will still require elevated admin rights. But any future updates to the source in C:\ptc\startup_scripts_3 will not, and the contents will be visible an accessible as if they existed under C:\ProgramData\...


mklink /D "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Creo 3 Software" "C:\ptc\startup_scripts_3\Creo 3 Software"

Using this approach, you don't have to mess with the permissions under ProgramData.


Symbolic links caneven reference network locations.


Use this command to see what is allowed by any Group Policies:


fsutil behavior query SymlinkEvaluation

I don't recall where I got the following code fragment, buthave used it to elevate a batch file using VBS on-the-fly.


 :: check for necessary permissions
"%SYSTEMROOT%\system32\cacls.exe" "%SYSTEMROOT%\system32\config\system" >nul 2>&1
if "%ERRORLEVEL%" NEQ "0" (
echo.
echo Elevated Administrative privileges are required
echo Set UAC = CreateObject^("Shell.Application"^) > "%TEMP%\getadmin.vbs"
echo UAC.ShellExecute "%~s0","<args here=">",","runas",1 >> "%TEMP%\getadmin.vbs"
cscript //nologo "%TEMP%\getadmin.vbs"
exit /B 5
)

I appreciate all the ideas that were floated.

My problem ended up being a syntax error in the script before it got to the xcopy line. The script was actually exiting before it completed. After fixing that syntax, the script completed and worked as expected.

There is another option, that would remove the necessity to "Run as Admin". That's to move that command from the install script to my post install script I have the users run.

This script sets up folders and cache location etc. In that script I could copy these files into the start menu that is unique to the user.

Like this:
echo d|xcopy "C:\ptc\startup_scripts_3\Creo 3 Software" "%USERPROFILE%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Creo 3 Software" /y /r /s /e

The other command copies these files to a Start Menu location that all users of the computer see:
echo d|xcopy "C:\ptc\startup_scripts_3\Creo 3 Software" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Creo 3 Software" /y /r /s /e

Copying the files to the %USERPROFILE%, means I don't have to mess with permissions on the folders.

Not sure which path I'll take yet.

David Haigh
TomU
23-Emerald IV
(To:davehaigh)

It's too bad you can't just run from the network. On a gigabit network it only takes an extra 10 seconds to startup vs. a local SSD drive. This means no local installation, no messing with the start menu, no messing with the user's profile, and no need to roll out new versions. We simply change one line in a centralized launch script and everyone is instantly "upgraded". The ONLY two things we install locally are Creo View (from Windchill) and the thumbnail viewer. Everything else runs from the network (including the Creo Agent).

Obviously for laptops we still install locally, and maybe if we had enough of those it would justify all the work you put in to automate it, but for now, for us, network installation is the way to go!

Tom U.

Must admit we also generally use network installs of all 14 cad variants we use with Windchill.



Currently developing a multi-cad launch tool that copies nay neccessary config for each system localy to the client (also has the advantage of giving users licence visibility before they launch CAD).


We do have some laptop users, but areinvestigating using windows'off-line' folders so that laptop users can sync the app they need locally when they need to work off-line.


If anyone has experience either good or bad on this last bit would be good to hear.



Cheers


Simon Lucas


I use off-line folders.

Great for start files, detail setup, formats, etc. Good for those times when you need to work on an airplane or other non-connected location.

Not so great for large libraries. I wouldn’t try to set those up as off-line folders.

On a slow VPN connection, you can sometimes have the system get confused and think your off-line. That can be a problem if your checking into Windchill.

when you’re on a VPN and don’t need the off-line feature, It’s best to go to my computer and access all the required network drives first, before you start Creo and connect to Windchill.

You will not want to have your setup files in Windchill, they need to be on a network drive. There is no automated way to sync what you have in Windchill with what’s on the network share. So you need to keep that in mind when you update files. For us, the only things we try to keep in sync are the formats. I maintain everything else outside of Windchill.

David Haigh
Top Tags