One person on my team found their VB6 IDE was no longer working. We eventually realized that the file VB6.EXE (from C:\Program Files (x86)\Microsoft Visual Studio\VB98) was missing and that this was because Symantec Endpoint Protection (14) had removed it due to WS.Reputation.1 (noted in Symantec logs).
I tried copying back the EXE from another PC and you could literally watch the file disappear from Explorer within a couple of seconds of being copied. Fail.
This only occurred on this single PC. Everyone here is using VB6 and has the same antivirus, so it is confounding why it happened only to a single person.
Could there be some factor unique to this one PC that caused this? If so (or if not...) how can we work around this?**
Other details:
New-ish PC, in use for about 2 weeks
VB6 had previously been working
Windows 10
Symantec Endpoint ver 14, corporate environment / centrally administered
Symantec's docs for WS.Reputation.1:
WS.Reputation.1 is a detection for files that have a low reputation
score based on analyzing data from Symantec’s community of users and
therefore are likely to be security risks. Detections of this type are
based on Symantec’s reputation-based security technology. Because this
detection is based on a reputation score, it does not represent a
specific class of threat like adware or spyware, but instead applies
to all threat categories.
The reputation-based system uses "the wisdom of crowds" (Symantec’s
tens of millions of end users) connected to cloud-based intelligence
to compute a reputation score for an application, and in the process
identify malicious software in an entirely new way beyond traditional
signatures and behavior-based detection techniques.
Report this false positive to Symantec to have it properly resolved:
https://submit.symantec.com/false_positive/
I submitted to Symantec and after 1-2 days I received the following reply:
Upon further analysis and investigation we have verified your
submission and, as such, the detection(s) for the following file(s)
will be removed from our products:
File name: VB6.EXE
MD5: 8AC4F5C29334B3C1B667B92EF860023A
SHA256: 971F73C9AC27EF3D50C1AC36D154674AB3A9957F967BFF6A62D5D18A75CFD910
Note: Whitelisting may take up to 24 hours to take effect via Live Update
Since I assume this is a truly global change, perhaps if this works it will work for other people also. However as noted above they may be taking action only for this exact version of the VB6 executable. If other editions of VB6 or various service packs changed this EXE I'm not sure if this will have an effect or not.
The info above pertains to VB6 with SP6 which is labelled "Version 9782" in Help > About.
Note: this did appear to work.
Related
I have a client site running our Windows desktop software on a number of computers with 64 bit Office 365.
On most of their computers, our software is able to send email via Outlook.
However, two of their computers were upgraded to 365 last year (by their IT technician, not us), and both fail when they attempt to send email from our software.
Outlook works fine on its own, and so does our software - on both of these computers. But these two both can't send email from our software. (The other computers, which send email fine, are running exactly the same version of our software.)
When sending email, our software first checks for the existence of "Outlook.Application" or "Outlook.Application.*" keys in the Windows Registry to determine whether Outlook is installed. If not found, our program logic assumes that Outlook isn't installed, and attempts to use MAPI instead to send mail through another email client like Thunderbird (or through Outlook using MAPI). However, these computers both then crashed, because MAPI doesn't work on 64bit computers.
When I investigated these two problem computers, I found that they both had no "Outlook.Application" or "Outlook.Application.16" keys anywhere in their Windows Registry. I have never encountered this before. How and why would Office 365 install without creating these Registry entries? (I had just installed Office 365 on two computers here in my office, and they both had these keys and worked perfectly. And we have never encountered this before, at any of our other user sites.)
I discussed this with their IT technician. He did a complete uninstall of Office 365, and installed them from scratch, using the "on-line" install (that I had used on my computers - I sent him the URL to be sure). However, after this they were still unable to send email. When I investigated, I found that the Registry keys were still missing.
Their IT technician then asked me to export all the "Outlook.Application" and "Outlook.Application.16" keys in "Computer\HKEY_CLASSES_ROOT" and send them to him. He imported these on both those computers, but it did not fix the problem.
However, because the keys now existed, our software then attempted to send email directly through Outlook, using OLE. However it crashed on the line where it tried to create an Outlook Application Object:
loApp = CreateObject("Outlook.Application.16")
I built a special version with some extra test code in it. After failing to run the above line, it tried to run a line:
loApp = CreateObject("Outlook.Application")
This also failed - presumably because some Outlook application components have not been installed.
I did some fairly extensive Google searches for posts that might identify a solution, but found nothing that seemed to fit. A couple of posts suggested running an Office "Repair" from the installation tool.
I mentioned this to their technician, and he did this. Interestingly, when I then checked (using RegEdit), it had created a lot more "Outlook.Application" and "Outlook.Application.16" Registry keys. But our software still fails on both the "CreateObject" lines in that test version, and single "CreateObject" line in the normal version.
Both their technician and I are completely mystified (and now out of our depth in the Microsoft black arts of Office 365 installation and Windows).
Has anyone encountered this scenario before, and / or can suggest where we might go from here?
OK, the original post was getting a bit long, and I didn't want to clutter it with too much information. So here is some further info:
In answer to Eugene's questions:
Using RegEdit, I searched the entire Registry - for one of the
computers that didn't work, and one that did (plus my own here,
which also worked fine).
Their technician installed the latest 64 bit 365. If I understand
correctly, the initial install was done from an ISO file. When that
didn't work, he tried again using the "on line" install (which I had
successfully used here). He used the "on line" install again for the "repair". I don't have current build numbers, but could obtain these later in the week if relevant. But they should be up-to-date.
No we can't reproduce the problem ourselves in-house, and have never
seen it before at any other client site.
The site is running the same antivirus software on all computers (those
that work, and those that don't). So I suspect that this won't be
the cause.
Registry keys that match perfectly on those two computers are:
Computer\HKEY_CLASSES_ROOT\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_CLASSES_ROOT\Outlook.Application
Computer\HKEY_CLASSES_ROOT\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Classes\WOW6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Backup\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\AppVMachineRegistryStore\Integration\Ownership\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Outlook.Application.16
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Classes\Wow6432Node\CLSID\{0006F03A-0000-0000-C000-000000000046}\InprocServer32
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\RegisteredApplications
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Classes\CLSID\{0006F03A-0000-0000-C000-000000000046}
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\RegisteredApplications
Something that may be significant:
The Windows Registry on the computer that does not work has four extra keys (that are not in the computer that does work):
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
That computer (which doesn't work) also has a folder C:\ProgramData\Packages\Microsoft.Office.Desktop.Outlook_8wekyb3d8bbwe\ with 3 subfolders in it (with system generated names):
The first (created in 2019) has a subfolder "\SystemAppData" which is
empty.
The other two (both with same date/time in early 2020) are completely
empty (i.e. have no SystemAppData subfolder)
I wonder whether these keys may somehow be causing mischief. Early next week the technician and I plan to back up these keys, and then delete them.
Does anyone know what these keys are about?
(I found a blog that may be relevant: https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/ But then again, it may not be.)
Keep in mind that older version of Windows Store Outlook ran in a sandbox and was not externally accessible. Uninstall it and reinstall again from the store - you will get a regular C2R version.
Eureka!!! Deleting those extra legacy Registry keys did the trick.
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16
Computer\HKEY_CLASSES_ROOT\PackagedCom\ProgIdIndex\Outlook.Application.16\Microsoft.Office.Desktop.Outlook_16051.12325.20298.0_x86__8wekyb3d8bbwe
Our software immediately was able to create Outlook Application objects, and send email via Outlook.
It seems that these extra keys dated back to an earlier attempted install by the client (before their current technician became involved). There were about 20 or so other 'Outlook*' keys in that part of the Registry with '8wekyb3d8bbwe' in their name. I subsequently deleted these too - on the the assumption that they were all legacy garbage. (As a rule, it is pretty dangerous to delete things you don't understand - but so far, so good. Although I am too chicken to delete a host of others in that location for Access, Excel, PowerPoint, Word with with '8wekyb3d8bbwe' in their name too.)
I had the same problem; it came from a brand-new computer!
What worked for me was the early binding. Select: Tools > Reference > Microsoft Outlook 16 object library.
Dim objOL As Outlook.Application
Set objOL = New Outlook.Application
Set objOL = Nothing
At the end, setting objOL to Nothing is crucial, otherwise the instance stays open, and it causes problems with Outlook.
Reference.
Our organization recently obtained an EV code signing certificate. It did give us instant SmartScreen trust, but 2 things still happen:
A minor annoyance was Chrome that issued a warning file.exe is not commonly downloaded and may be dangerous to first few downloaders but it went away within a day without us doing anything.
A much greater problem is Windows Defender. Here is what it does:
When our users install the program, it flags and locks crucial components that are required. This happens to most users.
We scanned the program components locally before uploading them and found no issues. Our Virus & threat protection is up to date. We also do not trigger antivirus protection when we download the same file from the website and install it as a normal user would. Why does it act so inconsistent that it doesn’t flag files when we download it from internet on our internal PC’s but it happens to most external users?
So far, we have been collecting these generic threat names and file names from our users and submitting them to Microsoft for analysis: https://www.microsoft.com/en-us/wdsi/filesubmission
It is very admirable that MS analysts review those files within a day, but what is not good is that they seem to update their antivirus definitions only for the threat name that was detected and not mark whole file as harmless. This problem gets even more frustrating because we update our installer often since program is in active development.
I am also worried that these updates with MS threat definitions are not properly disseminated to Windows users across the world fast enough. What happens if users do not update their definitions or have them turned off?
Is there anything that we are not doing yet, but could do to reduce issues with these false positives?
EV code signing certificate was issued by DigiCert and it was very expensive. Will these issues go away after MS scans signed files several times and increases trust score of our certificate? By that I mean, will it reduce the false positives on future builds that were not yet submitted for analysis?
First off, I read all other Questions, that relate to this, I did an extensive google search on this topic and could not get a working answer.
I installed the Community Version of Visual Studio 2015 in mid November and been using it since then. After finishing my project, I went back to pen and paper for new formulas and noe came back to implement all those neat things.
Now it says, that my trial license has expired and should be renewed. I already read, I should use my MicrosoftAccount to do that, and proceeded by doing that.
Now this happened
It says, I should check firewall and prxoy settings and I read about contactiong the administrator. So that, what I did, but he says, there is no proxy, no block by firewall or anything else.
When running VS as administrator (after entering my credentials) I can create new projects and debug existing ones, so no problem there. However I can not use the program as normal user.
I read somewhere here to try repair it via systemcontrol, but that did not work either.
Does anyone has a solution?
In addition: There is also no "Enter License Key here" field, so that is also not an option.
(several Days later)
Halleluja, I found the answer! After digging through some Microsoft Help-Forums, I came upon this Thread, that not only perfectly describes my problem, but also gives a solution. So dear visitor from the future, who googled the problem and came upen this Stackoverflow Question: Follow the link above!
So, after sniffing packets harder than a drug addict, trying to find a difference in TLS exchanges between my computer and VS licensing server when using a domain account and when a using local account, and noticing no difference, I recalled why I had pushed this hypothesis to the side: our network supports TLS 1.2 perfectly well, as I can connect to TLS 1.2-only remote hosts without any issue.
This means the issue lies elsewhere, and is caused by Visual Studio treating domain accounts and local accounts differently when trying to renew licensing information.
The good news is I've found why and how to fix it.
I recalled that earlier this year, when we upgraded our commercial department from Windows 7 to Windows 10, they all encountered issues while trying to configure their mail accounts on Microsoft Outlook: an unknown error 0x8004011c. If you search around for it you'll quickly find that this only happens when using domain accounts and not when using local accounts (sounds familiar, heh?). The fix to bypass this issue is to set a specific Windows cryptography-related registry key.
When digging a little deeper, you can find that this fix is related to KB 3000850 (which I sadly cannot link to due to my account not being verified) and is actually described in the "Known issues" section, as well as in Samba-related documentation ("Required Settings for Samba NT4 Domains").
In short: Windows 8.1+ clients (with KB3000850) joined to an NT-Style domain are not able to use Windows Credential Manager. This doesn't occur when not using a NT-Style domain. The fix seems to globally authorize using Windows Credential Manager whatever the domain context.
So, to wrap it up, if:
You have a NT-Style domain (such as when using a Samba domain controller)
You have Windows 8.1 or later
vYou encounter issues when renewing your Visual Studio license
Then, set the following registry key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb]
"ProtectionPolicy"=dword:00000001
This solved the issue on our domain, for all machines and accounts tested.
As to why Visual Studio 2015 needs to use Windows Credential Manager and not Visual Studio 2013, someone from Microsoft will have to chime in there to explain because I have no clue.
You are using a very old Samba server that uses unsupported features. NT4 came out in 1995. Active Directory didn't exist back then. A lot has changed in the last 20 years, including strengthening security and gradually removing older, less secure features like LanMan and NT4 domains.
Instead of weakening security, you should follow the advice posted in the page you linked, Required Settings for Samba NT4 Domains:
Microsoft discontinued the official support for NT4 domains in their Windows operating systems. ... Anyway, consider migrating to a Samba Active Directory (AD) to avoid problems if a future update from Microsoft disables or removes the unsupported NT4 features.
We have tremendous problems with Visual Studio (2008, if that matters) locking up and slowing down when accessing projects over a network drive. It can take several minutes to open a large Web site project through a mapped drive, and saving even a single file can take a minute or more.
I fired up Wireshark and watched the traffic. VS, it seems, requests massive amounts of files from the network -- there's an enormous amount of SMB traffic. I've done some research, and this traffic seems to stem from two situations.
VS has to have everything in its own process to provide Intellisense.
VS needs to have all the source in order to compile the project.
All the advice I've read seems to boil down to the same thing: work locally, not on a remote machine, then push your code to an integration server via source control.
This would sure solve our problems (VS is quite fast working locally), but what if you can't work locally? What if the project and the infrastructure required to run it is too large and complicated to be replicated on everyone's individual machines?
We've gone 'round this problem a couple times, and the only way we can figure to work on these projects is direct access via a mapped drive. However, the VS slowness and lockups are really becoming a problem.
One solution: we installed VS on the server and work on the projects directly on the servers via RDP. Seriously.
So, I ask:
What does everyone else do? Do you work via the network, or do you replicate projects locally? If remotely, do you suffer from VS performance issues.
We work locally and use SVN to keep all our code on the server.
I find VS 2008 quite slow working locally sometimes so I wouldn't fancy working on a network share.
Trying to compile over a network share is horribly slow using visual studio. Your start times will be bad as the intellisense database is regenerated. Each compilation has to go over the network multiple times. Linking takes forever.
If you need the output of your compilation on the network, I'd recommend doing your compile locally and defining a post-build command to copy the results to your share.
If, as you say, you cannot pull everything locally then I'd suggest your project is too big and needs to be broken up into more manageable chunks. For a multi-tier application, break it up by tier and invest in some form of continuous integration (e.g. CruiseControl) to automatically build individual pieces. In this way you can work locally on an particular piece and pull the pre-build portions from CI for the other pieces of the application.
I'm not terribly surprised that using VS to load projects over a network share has performance issues. VS (in any language) is constantly getting information from files in the project. Once you start loading this over a network you're at the mercy of the underlying network connection. All lags and access issues will directly translate into VS having an issue loading file contents.
I would advise copying the solution locally and using some form of source code control to sync the project on the share.
If the code is too complicated to install on everyone's machine, then don't put it on everyone's machine. Does everyone need to have everything in order to do productive work?
I have 79 projects in my solution that I work with. Several hundred thousand lines of code. I pull my source down everyday from TFS and build it; it's a lot of code, but it's a far better solution than trying to work over a network share.
A more legitimate situation of having the source code on a share is when one has a non-Windows host on which a (number of) virtual Windows machine is running.
I have this exact situation where my desktop machine (the host) is running Debian and I use VMware to run various virtual Windows machines (the guests), including one that has Visual Studio installed so that I can target Windows OS's. Having the source code on a Samba share on the host machine has the following pro's:
The source is not duplicated, so there is no way to confuse different copies while working on several virtual machines at the same time.
I have full control over the source from my preferred OS.
I can turn on and off any of the virtual machines, or roll back to a snapshot, without the risk of loosing changes.
I can build (etc.) from the same source on several machines without having to commit changes before the source fully tested (reason: I have to use Subversion <1.5).
The only problem with this setup is that Visual Studio (6,7,8,9) is painfully slow.
I have mounted the partition (on which the share lies) with "relatime" and this works in as far as the disk activity on the share moderate, but Visual Studio keeps the (virtual) network card occupied all the time.
Any solutions to this would be very appreciated.
I encountered similar problems everytime I worked (work = anything else then just copy / paste files) over a network drive. The problem occured with ZendStudio and Eclipse.
Why not use any kind of source control?
When working on Windows based projects I've always worked locally.
Once at a unix shop (AIX iirc) developers would work via NFS mount and checkin/checkout via RCS...
I'm using VS2005 across to a network share and not having any performance issues. However, it is a new server (Windows Server 2008). I don't have any other data points for VS since using it at work is relatively new for me.
However, some datapoints from using Netbeans for previous projects on a network share... Local build time for my project was 2 minutes on Vista, on a fast dual-core AMD 64-bit machine. For a network share project, on a Server 2003 box, it was 20 minutes. Building that same project from an ancient Tablet PC (1ghz, single core) running XP locally was around 5 minutes. Interestingly enough, the Tablet PC could build on the Server 2003 box in the same 5 minutes.
For those asking "why" on the network share. The network share is automatically backed up, archived, etc. Also, that way I can very easily look at the same projects from multiple machines without having to worry about pushing back into the repository, etc. Once you've gone to having your dev stuff on a device where you can get to it from anywhere/anything, you'll never want to do local storage again!
I have performance problems via network anything, they just aren't good enough yet.
I thought it was common knowledge that disk-speed is one of the major "slowness" factors when it comes to using VS in Windows. Most dev machines I've built have had projects located on 10k RPM RAID0 drives, or at least a single 10k RPM drive. And even then it seems slow sometimes. Just the way it is, I suppose, until VS2009/VS2010 fixes it? :)
From my experience, this lag when working on a network share is 99% due to Intellisense. Disable it and you'll see.
disabling Intellisense indeed speeds up saving and opening files trough a UNC share dramatically
http://blogs.msdn.com/saraford/archive/2007/12/03/did-you-know-how-to-turn-off-intellisense-by-default.aspx
but then again, as stated in other comments, you might as well use a good text editor
I've also experienced the problems with performance mentioned above. It seems to vary from project to project, but I did find one way of speeding up performance significantly for some project types.
Following the advice in this article made a previously unusable project on a network location (it would take minutes to open one file) perform almost like a local project. The basic gist is that you need to grant FULL TRUST to the network location:
To grant permission to all your projects in your Visual Studio Projects folder located on the network, follow these 8 steps:
Open Microsoft .NET Framework 1.1 (or 2.0) Configuration which you'll
find under Administrative Tools in the Control Panel.
Expand Runtime Security Policy | Machine, | Code Groups | All_Code |
LocalIntranet_Zone In the right-hand pane, click Add a Child Code
Group.
In the dialog that follows choose Create a new code group and fill in
a Name like Visual Studio Projects.
Optionally, provide a Description for the Code Group. (You'll see the
description when you click a Code Group in the left tree, helping you
identify the various Code Groups you may have) .
In the Condition Type drop down, choose URL
For the URL field, type something like this:
file://YourServer/My Documents/Visual Studio Projects/*
Under Use existing permission set, choose FullTrust (that is, if you
trust your own applications. If you don't, choose a different
permission set or create a new one).
Not sure why this works, but it made a previously unusable NET 2.0 project perform significantly better.
Original article: http://imar.spaanjaars.com/364/how-do-i-allow-my-visual-studio-net-projects-to-run-from-a-network-location
I was having the same problem. I have a local copy of our build system, which expects certain drive letters, and was also experiencing slowness.
I have solved the problem by adding the following registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices]
"R:"="\DosDevices\D:\devel\build
"S:"="\DosDevices\D:\devel\src"
Note that the double '\'s above are part of the .reg file format. When using regedit use single '\' throughout.
My build times were divided by 3. :)
I found the info in the wikipedia article on the SUBST command.
The title says it. I'm looking for a way to determine exactly which file/registry key this executable is attempting to access. I have attempted to use Windows auditing capabilities and Process Monitor to determine where the failure is happening but, this failure does not produce audit failure events or show as access denial in Process Monitor.
Of course, If someone has experienced this and can provide a solution to resolve the error directly that would be almost as nice.
Background:
I am using moveuser.exe which is part of the Windows Server 2003 Resource Kit Tools to convert the security of local user profiles on a number Windows XP workstations.
Symptom:
Occasionally, moveuser.exe will fail to convert the security of a profile with the error "Error: 5 access denied". I have not been able to determine any commonality among the failing accounts or the computers they reside upon. A given computer may have host 6 profiles, 5 of which convert without issue and 1 which produces the error.
There are a few factors that I'm as sure as I can be about:
-The account I'm using to run moveuser.exe with has full Administrator rights to the local machine and the domain to which the profile security is being converted.
-The failure is not related to file permissions within the profile directory (the entire directory can be moved, renamed, deleted, or successfully converted via a workaround).
I've developed a reliable workaround for these cases but, it is fairly involved and I would much rather understand the root cause of this error and correct it pre-emptively.
My workaround (glad to share it, left out for brevity) seems to indicate that the failure is related to HKEY_LOCAL_MACHINE \ SOFTWARE\ Microsoft\ Windows NT \ CurrentVersion \ ProfileList registry keys but, I cannot determine exactly how/why.
Did you try to use the "regini" command line tool to grab registry permissions for the administrator account?
Use FileMon and RegMon (now Microsoft, formerly SysInternals, still free) to monitor what exactly is being accessed, how, and what rights/access are being requested.
I don't have a URL handy, but a Google search should be able to hook you up with these tools.
A couple items I would try. First, could it be that the user was logged in and the computer hasn't been rebooted. Microsoft has a product called UPHClent which helps in unloading unneeded user hives.
Next thing I wanted to know, is if you try rebooting before running the moveuser executable. This Conversation seems to indicate this would help with this kind of error.
Two days after posting this I got to the bottom of the problem. It turned out, just as Rob Haupt suggested to be related to a stuck user hive. The program I was running, moveuser, was reading the Refcount key found under HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows NT\ CurrentVersion\ ProfileList\ <SID>\ and ending immediately.
Setting Refcount to 0 solved the problem immediately
Pushing out UPHClean to all the target machines pre-emptively has all but elimated the problem and we were able to successfully convert profiles on several hundred machines over the last week.
An important note about UPHClean:
I'd tried installing it previously but, it didn't appear to help. I was too impatient, the UPHClean ReadMe revealed that the service just takes time to do its job.