Does Sketchup support Sysprep and CopyProfile?

I work for a community college where students login to Windows-based computers using their Active Directory credentials.

We want it where all students can login to the computer and have the exact same Sketchup settings and exact same extensions/plugins. To do this for other programs, we typically use Sysprep and the CopyProfile setting in our unattend.xml file. The CopyProfile setting is the only official, Microsoft-supported method of copying a customized user profile to the default profile, which all new users will get the first time they login to the computer.

Should I expect this configuration to work, or should I expect problems? In other words, will all users have all the settings and have all the extensions/plugins?

SketchUp has never used the Default profile purposely. (I’ve brought up the subject in the past, but noone on the “team” cared to even discuss it.)
Regardless, since it’s an OS feature, any new profile should copy whatever you save to the Default profile, at the time the user profile(s) are created.
From that point on, SketchUp will be loading and saving to each individual user’s profile and their “user.dat” registry hive.

Re: Shared Plugins on specific workstations:
Shared plugins go in the %ProgramData% path, ie:

    %ProgramData%/SketchUp/SketchUp 2015/SketchUp/Plugins

and will be automatically loaded upon startup.

Shared Plugins on a network:
You’d put a rubyscript (like below) in an autoload folder, like the %ProgramData% plugins, as above:

# encoding: UTF-8

module YourSchool

  @@loaderrors = {}
  @@dir = "//path/to/some/shared/plugins"

    def dir()
    def errors()
      num = @@loaderrors.size
      if num == 0
        puts("\nNo LoadErrors for Shared plugins folder:\n  '#{@@dir}'\n")
        puts("\nLoadErrors for Shared plugins folder:\n  '#{@@dir}'\n")
        puts("#{num.to_s} Errors occured.\n")
        @@loaderrors.each {|f,e|
          puts("File: '#{f}'")
          puts("  #<#{}: #{e.message}>")
          puts(e.backtrace) rescue puts()

    def loaderrors()

    unless Kernel.test(?d,@@dir)
      puts("Warning! '#{File.basename(__FILE__)}': could not find:\n  '#{@@dir}'")
      raise(LoadError,"Unable to find directory: #{@@dir}",caller(0))
      $: << @@dir # push the shared directory into the $LOAD_PATH array.

  ### If @@dir cannot be found the load loop does not get evaluated!
    Dir.chdir(@@dir) do
      rbfiles = Dir["*.{rb,rbs}"]
      rbfiles.each {|f|
        ext = File.extname(f)
          ext == '.rbs' ? Sketchup::require(f) : require(f)
        rescue => e
          @@loaderrors[f]= e
          path = File.join(@@dir,f)
          if Sketchup.version.to_i < 14 # no rbs paths
            $" << path unless $".last == path || $"[-2] == path
            $" << f unless $".last == f || $"[-2] == f
            # rbs paths will be downcased on v14+
            $" << path unless $".last == path || $"[-2] == path
    end # chdir do
    unless @@loaderrors.empty?
      puts "Warning! '#{File.basename(__FILE__)}': could not load these files:"
      @@loaderrors.keys.sort.each {|f| puts "  '#{f}'"}
      puts "from dir: '#{@@dir}'\n"

end # module YourSchool

network_plugins.rb (2.0 KB)

Dan, that’s a lot of great information. Thanks for your extremely prompt reply!

To your knowledge, do the Sketchup folders and/or ntuser.dat registry hive contain any user-specific data, such as folder paths to the user’s directory?

I ask because, for example, AutoCAD has registry keys that specifically point to paths in the user’s folder. Because of this, when CopyProfile is used (or any method of copying a profile is used, for that matter), the original user’s paths are copied to the new user’s registry keys.

Just an example to illustrate the point:

Let’s say that I am logged in to Windows using the user “Administrator.” I install AutoCAD. I run AutoCAD for the first time, and it creates several folders under C:\Users\Administrator\AppData. It also creates registry keys under HKEY_CURRENT_USER. Those registry keys point to the folders under AppData that were just created. For example, one key might contain the path C:\Users\Administrator\AppData\Folder1.

I run Sysprep with the CopyProfile setting enabled, and the above folders and registry keys are copied to the default profile (C:\Users\Default).

Then, I login to Windows using a user named “User1.” I go to run AutoCAD, but none of the settings appear to have copied over. Instead, all the default settings are used. Why? Because the registry keys still point to the Administrator’s profile, such as: C:\Users\Administrator\AppData\Folder1. Sysprep is not “smart” enough to know to make these changes.

The fix, in the case of AutoCAD, is to simply change the registry paths to the correct user. So, for example, you would change C:\Users\Administrator\AppData\Folder1 to C:\Users\User1\AppData\Folder1 in the registry, and then everything works just fine because it can then access those folders. What we do is have a script run as soon as the user logs in that quickly makes these changes in the registry. So, the user is actually getting the incorrect paths at first, but the script runs so quickly that the user does not know that it was ever incorrect.

So…sorry for the extremely long and convoluted example. I’m just wondering if Sketchup requires anything similar, or whether it seems to be good to go without making any manual changes?

Just as a quick glance, I found the following that I could see as issues (I haven’t tested yet):

HKEY_CURRENT_USER\Software\SketchUp\SketchUp 2015\File Locations: This contains a bunch of C:\Users\[USERNAME] path keys, like these:

  • Classifications: C:\Users\[USERNAME]\AppData\Roaming\SketchUp\SketchUp 2015\SketchUp\Classifications\
  • Components: C:\Users\[USERNAME]\Documents\
  • Images: C:\Users\[USERNAME]\Documents\
  • ImportExport: C:\Users\[USERNAME]\Documents\
  • Materials: C:\Users\[USERNAME]\Documents\
  • Models: C:\Users\[USERNAME]\Documents\
  • Styles: C:\Users\[USERNAME]\Documents\
  • Textures: C:\Users\[USERNAME]\Documents\

Separately, I also noticed this directory:
C:\Users\[USERNAME]\AppData\Roaming\SketchUp\SketchUp 2015\SketchUp\Plugins

Are plugins stored here in addition to %ProgramData%/SketchUp/SketchUp 2015/SketchUp/Plugins? Or, are these just settings for the plugins?

First of all, applications are supposed to use expandable strings for paths in registry attributes, and then embed variables into the path strings.

So Sysprep should have taken this path:
and copied it to the Default user profile as:

Anything to be saved in the local (non-roaming workstation’s) user path would use the %LocalAppData% variable. This is true of the user’s %TEMP% directory.

Unfortunately, Sysprep does not do that that type of conversion. It only does that for Windows itself, not third-party applications. Other than Windows-related items, Sysprep quite literally copies the registry keys and AppData folders/files as-is.

If I were to manually convert the hard-coded items to variables (such as %AppData%), would Sketchup be able to expand it?

[quote=“loosus456, post:4, topic:4196”]
Just as a quick glance, I found the following that I could see as issues (I haven’t tested yet):

HKEY_CURRENT_USER\Software\SketchUp\SketchUp 2015\File Locations:

This contains a bunch of C:\Users\[USERNAME] path keys, like these:

  • Classifications:
    C:\Users\\[*USERNAME*]\AppData\Roaming\SketchUp\SketchUp 2015\SketchUp\Classifications\[/quote]
    You need to think in terms of
    instead of

[quote=“loosus456, post:4, topic:4196”]
It’s %USERNAME%, so:
or even better:
because the profile path may actually be on a remote / network drive (ie a server,), and not necessarily on the %SystemDrive%.

If you type set at the NT command prompt you’ll see a list of all the environment variables.
It does not matter whether you use them as all caps or mixed case.
%APPDATA% returns the same subpath as %AppData%


Yeah, I understand variables. I am typing it without the variables because that’s literally what the registry key contains. None of the Sketchup registry keys contain path variables, and that is why I believe they may cause problems if copied as-is.

[quote=“DanRathbun, post:7, topic:4196”]

FYI, the “Documents” paths are just there because this is the first install.
The user can change these via the Preferences dialog’s Files panel.

Then the SketchUp installer tries to “migrate” these paths from the previous installed version.
The reasoning is that the user has likely created some meaningful sub-directory structure under the “Documents” folder, as most of SketchUp’s associated files are considered documents.

I set (personally) up something like:

 +- SketchUp
      +- Classifications
      +- Components
      +- Images
      |     + Textures
      |     + Watermarks
      +- Materials
      +- Models
      |     + Export
      +- Styles

Of course they will.

Yes SketchUp was always set up as a single user-machine GUI application.

It’s only been a year (since the release of SU2014.) that some of the files were moved into the user path where they always belonged.

But because the older versions of SketchUp (2013 and earlier,) used Ruby 1.8.x, which did not have unicode string support, they had to leave user files in the binary (%ProgramFiles%) path.

The classifications and 4 standard Trimble extensions are distributed in the binary program folder, and copied over to the current user’s %AppData% path when SketchUp runs. Each time SketchUp starts it looks to see if these distro files have been copied, and if not will copy (or re-copy them, if you deleted them)

Thereafter… any updates via the ExtensionWarehouse for those extensions, will be deployed to the user’s %AppData% path,… not the “shipped” folders in the binary path.

I’ll need to do a quick test.

SketchUp has a nasty habit of overwirting registry values in a stupid way.
So it mat take the variable path and use it the first time say I open the import classification dialog,… but then may write the verbatim path back to the registry.

Ok the first test goes ok.

I replaced the “Classifications” path attribute value.

Started SketchUp, Then imported a classification system via the ModelInfo > Classifications panel, and the Import button.

The File open dialog opened in the correct folder.
The schema imported.
I closed SketchUp, and refreshed the view in the Registry Editor.
The path stayed as it was with the %AppData% variable.

The important thing is that the path was used without issue when opening the standard file picker dialog.
Once the user is running SketchUp, it should not matter if SketchUp writes user specific paths into their registry hive.

Ok the second test goes ok.

I replaced the “Components” path attribute value.

Started SketchUp.
Then right-clicked on the “Steve” component.
Chose “Save As”…

The File open dialog opened in the correct folder.
And I saved a copy of the “Steve.skp” component to my personal components folder.

I closed SketchUp, and refreshed the view in the Registry Editor.
The path stayed as it was with the %USERPROFILE% variable.

I re-opened SketchUp and the paths show with the variables, in the Preferences dialog:

It does, but Sysprep has no way of telling when a third-party registry key literally means “C:\Users\User1\AppData\Roaming” and when it simply means “%AppData%.” What if a software developer or end user intentionally and literally wanted a path to point to another user’s profile for some reason? If Sysprep went in and made that conversion, it may not be what you actually want.

Ideally, Sketchup should be taking better care of its registry keys. Any time a user sets a path in Sketchup to a user-profile directory, Sketchup should convert them to the variable equivalent on the fly. That would take care of most of the issues. In the (extremely rare) instance that you wanted the path without the variables, you could manually set them in the registry.

Uh… that is a no-no. The whole reason for profiles is to allow users privacy from snoopy other users.

A “Standard User” can only access their own profile hierarchy. They will be denied access if they try to say, enter some other user’s “Documents” directory.

They can however access the “Public” profile.

I’m not sure about the “Default” profile, that may be only Administrators.
Administrators can access any profile.

Thanks for the tests, Dan. It sounds like Sketchup will indeed work with the variable versions of the paths, which is good news.

I may do a test of copying the entire folder and registry keys to the default profile to see if all settings are correctly copied.

The only remaining thing that I am slightly concerned about is whether there are any additional user-specific paths that I am not aware of. I looked through the registry keys, and I don’t see any, but I can’t realistically check the contents of every file under %AppData%\SketchUp because some of them may not even be plain-text files (i.e., they may be binary data files).

I really wish the SketchUp folks had an official way of generalizing the settings files. It would (a) be more reliable since it’d be from the horse’s mouth and (b) give me less heartburn trying to figure this out after every new release of SketchUp.

While I agree with everything you’re saying in principle, I can tell you from experience in a corporate environment that there are many, many times when I have been forced (possibly against my will) of giving a user access to part of another user’s profile. Usually, this happens on computers that are not considered “office” machines but are used for one specific purpose.

The “Public” folders are only partially writable by users in the “Users” group, by default.

It also happens in the rare (and stupid) cases where we are forced to allow, say, a supervisor employee to place files on the desktop of a subordinate employee’s desktop. The “Public” desktop would allow all users of the computer to see those files, and users that are part of the “Users” group do not have write/modify access to the “Public” desktop by default, anyway.

Yes, “C:\Users\Default” is only accessible by members of the “Administrators” group, unless other users or groups have explicitly been given that permission.

I think that the HKEY_LOCAL_MACHINE has some installation paths, but into the %ProgramFiles% paths.

The SketchUP binary / program folders:

We Do still have a few issues (on MS Windows,) that I am still politicking to get changed.
I start adding them here, but it might take a few days for me to remember them and add them here.

(1) Templates

Custom user templates are saved into the binary path, without any choice to save them elsewhere, when the “Save As Template” (“File” menu) option is used.

If the “Standard User” does not have write permissions for the “SketchUp 2015/Resources/en-US/Templates” directory, an error occurs, or the file is instead SILENTLY saved into the user “%LocalAppData%/VirtualStore/Program Files/SketchUp/SketchUp 2015/Resources/en-US/Templates” directory (… Windows actually creates the virtual directories.)

This is no help as SketchUp does not go looking there for user templates.

(1)(a) SketchUp will not look in the user %AppData% path, unless the Templates directory is physically moved into the user %AppData% path.
This is probably a bad idea as any update / maintenance release is likely to recreate the Templates directory in the binary path, thereby shutting off users from their custom templates.

(2) Styles

The only way to set up a user’s appdata “Styles” folder ahead of time is to use a symbolic link:
At the NT console, an Administrator must navigate to the SketchUp program “Styles” sub-directory, and enter:
C:\Program Files\SketchUp\SketchUp 2015\Styles>mklink /D "User Styles" "%USERPROFILE%/Documents/SketchUp/Styles"
If it works you see:
symbolic link created for User Styles <<===>> C:\Users\Dan/Documents/SketchUp/Styles

When you start SketchUp you’ll see the link “User Styles” added to all the rest of the listed Styles directories, in the Styles inspector:

Yikes. I just noticed the “Save As Template” issue. I am logged-in as an admin and have UAC turned on, so I got a UAC elevation prompt as soon as I tried to save the custom template.

I could totally understand saving to Program Files as an option for administrators, but that seems like a terrible design for corporate environments. Most corporate environments do not allow users to have admin rights. In fact, we do not allow admin rights on any computers that are used by employees.

For students in our lab environments, we luckily do give students admin rights (but the lab computers are frozen using DeepFreeze to prevent most damage across reboots).

It’s not so much by design as because old versions of SketchUp could not deal with (or actually the old Ruby 1.8,) could not handle unicode usernames in path strings.

So they waited and waited until after Trimble bought the product and was willing to fund the Ruby updated to 2.0 with unicode support.

That allowed moving the plugins into the user path, which was the real “biggie”. They also set up the classifications in the user path because they were first developing that feature, and could go ahead with that, without worry something else would break.

Templates, Styles, Components and Materials all need better user path support.