Wow this one killed me. After attempting to determine why I simply could not install Adobe DC with our package from enterprise (though only on certain machines) I really had to dig into this one. The package would first fail with a generic:
Product: Adobe Acrobat DC - Update 'Adobe Acrobat DC (15.006.30060)' could not be installed. Error code 1603.
Knowing that this is a very generic error code, I began digging through a "l*v" generated log to determine the true source of the failure.
MSI (s) (84:88) [14:36:07:292]: Product: Adobe Acrobat DC -- Error 1328.Error applying patch to file C:\Config.Msi\PT2AFE.tmp. It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor. System Error: -1072807676
Error 1328.Error applying patch to file C:\Config.Msi\PT2AFE.tmp. It has probably been updated by other means, and can no longer be modified by this patch. For more information contact your patch vendor. System Error: -1072807676
Aha, so it appeared that for some reason the MSP packaged with the MSI was failing to be applied. Scrolling up through the log I was able to identify the actual failing file itself:
MSI (s) (84:88) [14:36:07:292]: Executing op: CacheBaselineFile(Baseline=0,FileKey=adobe_caps.dll,FilePath=C:\Program Files (x86)\Adobe\Acrobat 2015\Acrobat\adobe_caps.dll,,Existing=0)
MSI (s) (84:88) [14:36:07:292]: Executing op: PatchApply(PatchName=adobe_caps.dll,TargetName=C:\Program Files (x86)\Adobe\Acrobat 2015\Acrobat\adobe_caps.dll,PatchSize=81904,TargetSize=552632,PerTick=0,,FileAttributes=16384,PatchAttributes=0,CheckCRC=0)
MSI (s) (84:88) [14:36:07:292]: Patch for file 'C:\Program Files (x86)\Adobe\Acrobat 2015\Acrobat\adobe_caps.dll' is redirected to patch 'C:\Config.Msi\PT2AFE.tmp' instead.
At this point I needed to dig deeper--I know that the package installed perfectly on other machines, so why not this one? Firing up Procmon, I was able to see that msiexec.exe was hitting the "adobe_caps.dll" file here:
C:\Windows\Installer\$PatchCache$\Managed\68AB67CA3301FFFF7706E0F060571500\15.6.30033
Being unfamiliar with the "$PatchCache$" folder, I did a little research and found that files can be cached here (and only cached ONCE) for any MSP file installed on your machine. Since the installer was being pulled across the network, it looks like a network hiccup occurred and a corrupt version of the "adobe_caps.dll" (showing as 0 KB) was stored in cache.
To resolve the error, all that needed to be done was to remove the entire "68AB67CA3301FFFF7706E0F060571500" folder & reinstall! Bam!!
Wednesday, December 2, 2015
Thursday, November 19, 2015
Getting NW.js (node-webkit) v0.12.3 to work with Edge.js
This is something I needed to get functioning for work. Luckily it wasn't so difficult--the hardest part was attempting to figure out why after I compiled Edge.js properly for NW.js v0.12.3 why it wouldn't actually attempt to load the native "edge.node" module.
First things first, we need to make sure the following is installed on your machine:
Windows 7 SDK 7.1
Since I already do quite a bit of development on my machine I was lucky to already have VS 2013 & the Windows 7 SDK 7.1 installed.
Next, go ahead and open up the "Windows SDK 7.1 Command Prompt" from the start menu.
For the next steps, Vijay Kumar has provided some excellent steps here:
Unfortunately it wasn't so simple as it appeared my corporate proxy was blocking or throwing 403 errors when nw-gyp was attempting to pull the NW.js headers from the Amazon AWS site. After looking through a bit of the code, I discovered "install.js" did in fact contain proxy support:
setenv /x64
At this point, my custom "edge.node" was building properly:
Boo! As it turns out, the error does in fact state Edge appears to be looking for a "v1.2.0" folder. Digging into the Edge.js code more, I discovered the following under "node_modules/edge/lib/edge.js":
var versionMap = [
[ /^0\.8\./, '0.8.22' ],
[ /^0\.10\./, '0.10.0' ],
[ /^0\.12\./, '0.12.0' ],
[ /^4\./, '4.1.1' ]
];
Aha! So since Edge is looking to match v1.2.0, I went ahead and modified the above to so:
var versionMap = [
[ /^0\.8\./, '0.8.22' ],
[ /^0\.10\./, '0.10.0' ],
[ /^0\.12\./, '0.12.0' ],
[ /^4\./, '4.1.1' ],
[ /^1\.2\./, '1.2.0' ]
];
Then proceeded to create the following directory:
node_modules/edge/lib/native/win32/x64/1.2.0
And finally dumped all the files from the "0.12.0" files into this folder. After copying the files over, boomzy:
Hope this saves someone a headache.
-CJ
First things first, we need to make sure the following is installed on your machine:
Windows 7 SDK 7.1
Since I already do quite a bit of development on my machine I was lucky to already have VS 2013 & the Windows 7 SDK 7.1 installed.
Next, go ahead and open up the "Windows SDK 7.1 Command Prompt" from the start menu.
For the next steps, Vijay Kumar has provided some excellent steps here:
Brief procedure for some one who might be interested.
My code was in the directory C:\tdameri\xlsxcplus\test1
I used the Windows 7 SDK 7.1 command prompt (you need to have Windows 7.1 SDK installed)
Commands in the command promptsetenv /x86
cd C:\tdameri\xlsxcplus\test1
npm install edge
cd C:\tdameri\xlsxcplus\test1\node_modules\edge
nw-gyp configure --target=v0.8.4
nw-gyp buildThe build happened without errors.
Copy the edge.node file from edge\build\release folder
and replace the edge.node files the edge\lib folder.
Unfortunately it wasn't so simple as it appeared my corporate proxy was blocking or throwing 403 errors when nw-gyp was attempting to pull the NW.js headers from the Amazon AWS site. After looking through a bit of the code, I discovered "install.js" did in fact contain proxy support:
Woohoo! I was able able to simply SET my "HTTP_PROXY" environment variable and move forward. A quick note is that Vijay was building for x86 while I was building for x64, therefore, the only change I needed from his steps was modifying the first line to:// basic support for a proxy server var proxyUrl = gyp.opts.proxy || process.env.http_proxy || process.env.HTTP_PROXY || process.env.npm_config_proxy
setenv /x64
At this point, my custom "edge.node" was building properly:
Following Vijay's steps above, I found that even though we have build "edge.node," we now need to copy it from:
node_modules/edge/build/Release/edge.node
Over to:
node_modules/edge/lib/native/win32/x64/
Speaking of my old friend Vijay--it looked like he didn't realize which folder to copy the newly compiled binary to. In my case, I figured if I was running NW.js v0.12.3--why not copy it over to the "0.12.0" directory?
Thinking I was in the clear I attempted firing up NW.js and discovered to my horror:
var versionMap = [
[ /^0\.8\./, '0.8.22' ],
[ /^0\.10\./, '0.10.0' ],
[ /^0\.12\./, '0.12.0' ],
[ /^4\./, '4.1.1' ]
];
Aha! So since Edge is looking to match v1.2.0, I went ahead and modified the above to so:
var versionMap = [
[ /^0\.8\./, '0.8.22' ],
[ /^0\.10\./, '0.10.0' ],
[ /^0\.12\./, '0.12.0' ],
[ /^4\./, '4.1.1' ],
[ /^1\.2\./, '1.2.0' ]
];
Then proceeded to create the following directory:
node_modules/edge/lib/native/win32/x64/1.2.0
And finally dumped all the files from the "0.12.0" files into this folder. After copying the files over, boomzy:
Hope this saves someone a headache.
-CJ
Wednesday, May 6, 2015
ServiceStack v3, Angular, IIS Express, Windows Authentication & CORS
I've recently busted my balls trying to get ServiceStack v3/Angular/IIS Express/Windows Authentication all working together in our corporate environment. It was a bit of a nightmare but it appears I finally have it all figured out. Sorry about the crappy formatting.
First of all, I am running Visual Studio 2010 so I needed to ensure that SP1 was installed so I could properly configure my site from the Properties dialog of solution explorer. First things first, you'll need to ensure that both Anonymous Authentication & Windows Authentication are enabled on the site:
After this is added, implement Demis' (mythz) fallback service documented here (http://stackoverflow.com/questions/19254512/servicestack-corsfeature-global-options-handler-not-firing-on-certain-routes):
Request:
[FallbackRoute("/{Path*}")]
public class Fallback
{
public string Path { get; set; }
}
Service:
public class FallbackService : Service
{
public object Any(Fallback request)
{
if (base.Request.HttpMethod == "OPTIONS")
return null;
throw HttpError.NotFound(String.Format("{0} was not found", request.Path));
}
}
And finally you'll need to add the following to your AppHostBase in Global.asax:
base.Plugins.Add(new CorsFeature(
allowedOrigins: "http://FrontendUrlHere", allowCredentials: true, allowedMethods: "GET,POST,PUT,DELETE,OPTIONS"
));
Be sure you replace "FrontendUrlHere" with your front-end URL. Allowed origins of "*" do not work when allowCredentials is set to true due to security reasons.
First of all, I am running Visual Studio 2010 so I needed to ensure that SP1 was installed so I could properly configure my site from the Properties dialog of solution explorer. First things first, you'll need to ensure that both Anonymous Authentication & Windows Authentication are enabled on the site:
Once you've confirmed both are enabled, head over to your web.config file and be sure you ad the following to the system.web section (OPTIONS simply would not work with Windows auth):
<system.web> <authorization> <allow verbs="OPTIONS" users="*"/> <deny users="?" /> </authorization> </system.web>
After this is added, implement Demis' (mythz) fallback service documented here (http://stackoverflow.com/questions/19254512/servicestack-corsfeature-global-options-handler-not-firing-on-certain-routes):
Request:
[FallbackRoute("/{Path*}")]
public class Fallback
{
public string Path { get; set; }
}
Service:
public class FallbackService : Service
{
public object Any(Fallback request)
{
if (base.Request.HttpMethod == "OPTIONS")
return null;
throw HttpError.NotFound(String.Format("{0} was not found", request.Path));
}
}
And finally you'll need to add the following to your AppHostBase in Global.asax:
base.Plugins.Add(new CorsFeature(
allowedOrigins: "http://FrontendUrlHere", allowCredentials: true, allowedMethods: "GET,POST,PUT,DELETE,OPTIONS"
));
Be sure you replace "FrontendUrlHere" with your front-end URL. Allowed origins of "*" do not work when allowCredentials is set to true due to security reasons.
Friday, April 3, 2015
PsExec -- Error deriving session key: The system cannot find the file specified
So this one's been driving me insane for a while (especially since I figured it out a while ago and never documented the solution). On some systems I would only be able to get PsExec working half the time...the other half the time I'd receive this infuriating error:
So after running ProcMon to determine what file "couldn't be found," I realized--I was running PsExec as my elevated administrative user without a profile. As in: runas /noprofile /user:chrl\CJ cmd.exe. Unfortunately, this doesn't seem to work due to something with HKCU cryptographic keys.
Either way, the issue went away once running under my elevated account without the /noprofile switch. Hope this saves someone a headache.
C:\Users\CJ\Downloads>psexec \\chrlcltsbx803 -i -s cmd.exe
PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
Error deriving session key:
The system cannot find the file specified.
PsExec v2.11 - Execute processes remotely
Copyright (C) 2001-2014 Mark Russinovich
Sysinternals - www.sysinternals.com
Error deriving session key:
The system cannot find the file specified.
So after running ProcMon to determine what file "couldn't be found," I realized--I was running PsExec as my elevated administrative user without a profile. As in: runas /noprofile /user:chrl\CJ cmd.exe. Unfortunately, this doesn't seem to work due to something with HKCU cryptographic keys.
Either way, the issue went away once running under my elevated account without the /noprofile switch. Hope this saves someone a headache.
Thursday, April 25, 2013
Lync 2010 Error Code: 500 Internal Server Error. The received certificate has expired. (-2146893016)
This summary is not available. Please
click here to view the post.
Monday, June 11, 2012
Hyper-V Server 2008 - Error: 'The requested operation could not be completed due to a file system limitation'
When attempting to attach a VHD (or simply create a new virtual machine for that matter) by utilizing the Hyper-V manager on a remote computer (to manage Hyper-V Server 2008) I was having issues--I was receiving the error Error: 'The requested operation could not be completed due to a file system limitation' which was not too simple to figure out.
Turns out I was attempting to use a UNC path to point to the VHD (as I figured I would have to). This is not the case--instead, in the management console on the remote machine I needed to use the local path on my actual Hyper-V server.
This resolved my issue.
Turns out I was attempting to use a UNC path to point to the VHD (as I figured I would have to). This is not the case--instead, in the management console on the remote machine I needed to use the local path on my actual Hyper-V server.
This resolved my issue.
Monday, April 16, 2012
Exchange 2003--How to force message stuck in 'Messages with an unreachable destination' to retry
I was in the middle of a migration from Exchange 2003 to 2010 and was troubleshooting public folder replication when I noticed my replication emails to the new public folder database were stuck in the unreachable messages queue.
The solution is to simply restart the SMTP service:
net stop smtpsvc
net start smtpsvc
Then the messages flowed out the appropriate connector.
The solution is to simply restart the SMTP service:
net stop smtpsvc
net start smtpsvc
Then the messages flowed out the appropriate connector.
Labels:
Exchange 2003,
Exchange 2010,
queue,
SMTP,
unreachable destination
Friday, July 1, 2011
Exchange 2010 HTML Mailbox Size Report
Not the prettiest thing in the world but gets the job done by printing each user's mailbox size & total items into a HTML table:
get-mailbox -database "Mailbox Database 1706745955" | get-mailboxstatistics | where {$_.objectclass -eq "Mailbox"} | sort-object totalitemsize -descending | select-object @{label="User";expression={$_.DisplayName}},@{label=
"Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{label="Items";expression={$_.ItemCount}} | convertto-html | out-file report.htm
May need to modify the mailbox database name.
get-mailbox -database "Mailbox Database 1706745955" | get-mailboxstatistics | where {$_.objectclass -eq "Mailbox"} | sort-object totalitemsize -descending | select-object @{label="User";expression={$_.DisplayName}},@{label=
"Total Size (MB)";expression={$_.TotalItemSize.Value.ToMB()}},@{label="Items";expression={$_.ItemCount}} | convertto-html | out-file report.htm
May need to modify the mailbox database name.
Labels:
Exchange 2010,
Mailbox-Size,
Powershell,
Report
Thursday, February 10, 2011
Windows Vista Update Error 0x80072EFD
Could not update Vista SP1 due to 0x80072EFD error, so I started out by manually updating to SP2. No success. This was driving me absolutely insane until I actually read the C:\windows\windowsupdate.log file.
First, try resetting the HTTP proxy through an elevated command prompt with the following command:
If you are still receiving this error, be sure you follow this KB:
http://support.microsoft.com/kb/836941
If this does not resolve the problem, try resetting Windows Update Components with the following Microsoft Fix It:
http://support.microsoft.com/kb/971058
If this still does not work, be sure that WSUS GPO & registry settings are NOT in place!
First check GPO:
Administrative Templates->Windows Components->Windows Update, under the setting "Configure automatic updates." If this is already set to "Not configured," then check registry settings under:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
For any WSUS keys. Deleting the WSUS keys I found in the registry remediated my issue.
First, try resetting the HTTP proxy through an elevated command prompt with the following command:
netsh winhttp show proxy If you are still receiving this error, be sure you follow this KB:
http://support.microsoft.com/kb/836941
If this does not resolve the problem, try resetting Windows Update Components with the following Microsoft Fix It:
http://support.microsoft.com/kb/971058
If this still does not work, be sure that WSUS GPO & registry settings are NOT in place!
First check GPO:
Administrative Templates->Windows Components->Windows Update, under the setting "Configure automatic updates." If this is already set to "Not configured," then check registry settings under:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate
For any WSUS keys. Deleting the WSUS keys I found in the registry remediated my issue.
Labels:
Error 0x80072EFD,
SP1,
SP2,
Windows Update,
Windows Vista,
WSUS
Tuesday, February 1, 2011
Android Corporate Exchange Setup - Username or Password Incorrect
I spent a lot of time ensuring ActiveSync was working properly for a client on Exchange 2010--they have a lot of iPhones and I wanted to be sure everything top-notch.
When attempting to activate a Motorola Droid 2 with the Exchange server, I kept receiving the error "Username or password incorrect" despite the fact that the username & password were both in fact correct. I was also unable to enter a server name no matter what.
I managed to solve the issue by entering a completely incorrect email address (user@blah.com) before finally being prompted for the server. After entering the FQDN of the mail server, I was able to successfully authenticate the account.
When attempting to activate a Motorola Droid 2 with the Exchange server, I kept receiving the error "Username or password incorrect" despite the fact that the username & password were both in fact correct. I was also unable to enter a server name no matter what.
I managed to solve the issue by entering a completely incorrect email address (user@blah.com) before finally being prompted for the server. After entering the FQDN of the mail server, I was able to successfully authenticate the account.
Subscribe to:
Posts (Atom)
