SharePoint Content Organizer – Emailing Your Drop Off Library, And Getting It To Work…

2017-07-27T00:01:08+00:00 January 25th, 2012|Uncategorized|

Recently I bumped into a problem in SharePoint Content Organizer while trying to set up my Drop Off Library’s email, and I thought I’d pass along the fix.

The Incoming E-Mail Oddity

I’ll assume anyone reading this already understands the basics of setting up their SharePoint Content Organizer with fun and exciting rules and folder settings. Once you have these configured, you’re able to create an email scenario which — when turned on — allows users to send attached documents to the Drop Off Library. 

Drop Off Library > Library Tab > Library Settings > Communications > Incoming e-mail settings

 

Once you’ve done this, you probably think, “YES! Let me start emailing away and having the documents sorted into the folders…”  At least this is what I thought — not so lucky my friend. 

I hit a snag; when I emailed documents to the email address I created, the documents just sat in the Drop Off Library and wouldn’t listen to the rules.  The real frustrating part was when I clicked on “View Properties” — and then closed it without any changes — it would listen to the rules and perform the actions….

How to Actually Make it Work

The only thing you have to do to get your emailed documents to follow your rules is set the run timer in the SharePoint Server!

Central Administration > Monitoring > Review Job Definitions (under Timer Jobs) > Content Organizer Processing

 

Once you do this you can set it to “Run now”, run every X amount of minutes/hours, or at a certain point in the day.

I hope that helps!

 

 

Application Virtualization – The UAC Panacea?

2017-07-27T00:01:08+00:00 January 18th, 2012|Uncategorized|

…with contributions from Aaron Gierak, Voltaire Toledo, and Jeremy Pavlov.

The User Account Control (UAC) Challenge

It is commonly known that in XP you have to give end users Administrator privileges in order to do even the most simple routine tasks; like changing the system clock, plugging in a USB drive, running a defrag, updating software, or even running security products.  Of course you can use the RunAs command, but that still requires having an Administrator password – which defeats the security purpose of a limited user account.  And just when we thought moving to Windows 7 would eliminate this security privilege nightmare, enter UAC…

User Account Control (UAC) is a technology aimed to improve the security of Microsoft Windows by limiting application software to standard user privileges until an administrator authorizes an increase or elevation.  In this way, only applications trusted by the user may receive administrative privileges, and malware should be kept from compromising the operating system.  In other words, a user account may have Administrator privileges assigned to it, but the applications that the user runs do not inherit those privileges unless they are approved beforehand, or the user explicitly authorizes it.

It is possible to turn off UAC while installing software, and re-enable it at a later time.  However, this is not recommended since File & Registry Virtualization is only active when UAC is turned on – and if UAC is switched off, user settings and configuration files may be installed to an unintended location (i.e. a system directory rather than a user-specific directory).  Also Internet Explorer 7’s “Protected Mode” – whereby the browser runs in a sandbox with lower privileges than the standard user – relies on UAC; and will not function if UAC is disabled.

The Application Virtualization Question

So is application virtualization the solution?  If a virtualized package runs at the kernel level, does it eliminate having to give an XP user Administrator rights?  When you repackage an application that you have been running in XP – in order to port to Win7 – does the app skate by UAC in a way that allows you to keep UAC turned on?

By default, UAC virtualizes requests for protected resources to provide compatibility with applications not developed for UAC.  This is important because many applications written for Windows XP and earlier operating systems assume that the user has administrative privileges and attempt to write to protected resources such as the Program Files or System folders.  The first time an application makes a change to a virtualized resource, Windows copies the folder or registry key to the location within the user’s profile.  Then, the change is made to the user’s copy of that resource.  UAC virtualization is designed to allow already-installed applications to run successfully with standard user privileges, even if they store temporary files or logs in a protected folder.

Installs, Upgrades, and Updates

Many of the problems with UAC come from application installs or upgrades/updates where a new driver or an action that requires UAC acceptance is needed.  With application virtualization – especially a tool like Symantec’s Workspace Streaming where you package from the kernel level – you can bundle the drivers *inside* the virtual app.  As a result, nothing would ever be required of the end-user since nothing is ever “installed”. 

Secondary Executions

However, another issue that bumps against UAC is what we commonly call the “Secondary Execution Event”, where a loaded executable decides to make a call on its own (outside of the one that the app designer intended).  For instance, if a permitted/intended executable launched, and then it calls out to the manufacturer for an updated version, or the latest driver, that is not pre-bundled in the package.  Examples of this are the Juniper VPN agent or the MS Security Center executable.

Panacea or Pariah?

The good news is that application virtualization absolutely does address UAC and elevation features by isolating areas that normally prevent non-elevated users from writing to them by creating a virtual HKLM registry hive, Windows and Program Files.  Virtualizing applications also mitigates potential conflicts in a shared session environment like Remote Desktop Servers or XenApp.

However, is application virtualization the silver bullet to fix all elevation and UAC issues?  The answer is “it depends”.  If the application explicitly requires elevated privileges within its manifest, then it will always present a UAC prompt.  In addition, if the application attempts to make a system change like a driver installation or some kind of self-updating feature, it will force Windows 7 to prompt you for elevation.  These challenges can be further addressed with tools such as AppSense Application Manager, or Viewfinity Privilege Management (which elevate a user’s privilege on a per-executable basis), or SystemGuard (which can elevate privileges to write to the registry).

The bottom line is that application virtualization brings many advantages.  In addition to extending the life of legacy applications, reducing deployment costs, and reducing user downtime caused by install/uninstall issues and application conflicts, many UAC issues can be mitigated with application virtualization, especially when coupled with effective use of user virtualization tools.

 

Next installment – Application Streaming…

 

The impact of the Forgotten Harvest organization….

2017-07-27T00:01:08+00:00 January 11th, 2012|Uncategorized|

I had heard about the work that the Forgotten Harvest organization does many times before; on the radio, from friends, and from some of the stories from organizations that have benefited from their work.  But in a lot of ways, the breadth and scope of what the Forgotten Harvest folks do was lost on me — much like the way that one cannot fully grasp the breadth and scope of the Grand Canyon from stories alone… until you see it for yourself…

I — along with a group of Coretek folks — got to experience first-hand what Forgotten Harvest is all about when we dropped by the organization on January 4th.  With the comforts of the recent holidays and family events still upon us like a cozy sweater, and the excitement of the new year in our eyes like a glistening ray of hope, we sat down and got a dose of reality in the form of a quick lesson on some staggeringly distressing hunger statistics — and what the Forgotten Harvest organization is doing to remedy the problem (for examples of what we learned, please see the 2010 Forgotten Harvest Annual Report). 

We were immediately and deeply affected from the explanation of the vast needs of the community, the vast waste of food, and how these two things had no meaningful correlation before this wonderful organization began to stem the tide and actually solve two problems… just by being smart about them both.

And after a brief explanation of the work we’d be doing during our visit, we split up into teams and headed back under the guidance of Mike, our friendly shop Sargent and guide/instructor. 

For the next few hours, half of our group packaged grapefruit from large pallets into small bags and containers for easy distribution to food centers, shelters, etc.  These are perfectly good grapefruit that were just a tad too large, or bumpy, or green, and would not have sold well on a store shelf — and would otherwise end up in a landfill!  Pallet, after pallet… after pallet…  …of perfectly good fruit.

Meanwhile, the other half of our group went into a special section to work on packaging up beef jerky “ends” and “bent” pieces; fresh from the factory, perfectly good, but not fit for the grocery store packaging.  Bag after bag, after bag, of jerky was loaded onto pallet after pallet after pallet.   This is what I meant about the “Grand Canyon” simile above…

Out of the 40-43 participants, in about a 2+ hour time period, we packed roughly 8000 lbs. of food (5000 lbs. grapefruit, 3000 lbs. meat snacks).  Of course, being competitive people by nature, we couldn’t help making a bit of a contest out of the grapefruit vs. jerky teams (yay grapefruit!).  And while we were happy and proud to contribute the best way we could, everyone in the room became fully aware of the size of the challenge, the scope of the effort, and our small place in it.

It was a great experience.  I hope you will take a moment to find out more about the Forgotten Harvest organization, and see if you might be able to volunteer some time to help.

I know we’ll be back.

 

Logging Windows Installer transactions…

2012-01-04T23:42:41+00:00 January 4th, 2012|Uncategorized|

Building and deploying Windows packages in enterprise deployments can be a challenge when it goes smoothly, but especially difficult when the package deployment hits bumps in the road.  Just when you think you’ve got that application perfectly bundled, tested, and deployed, an unforeseen interaction can knock the legs out from under you.

And of course, the behavior of  Windows Installer itself can be frustrating and may even seem a bit mysterious; making app deployment even more of a challenge.  The installer follows very explicit rules for everything it does, and enforces them rigidly.  Creating a log file for an .MSI installation might just be the saving grace – providing insight when troubleshooting installation errors and other unexpected behavior.

Most application packagers are aware that a verbose log file can be can be generated by passing the parameter /l*v install.log to the Windows Installer engine  (msiexec.exe).  But what about when Windows Installer unexpectedly initiates a “self repair”, or errors occurs during an application uninstall?

Here’s one thing that can help:  There is a registry value that can be set which causes all Windows Installer transactions on a system (installs, uninstalls, repairs, etc.) to be logged to a file.  Just add the following key to the registry:

Warning:  Don’t goof around in the registry if you don’t know what you’re doing.  Seriously.  Don’t.

Registry key: HKLMSoftwarePoliciesMicrosoftWindowsInstaller
Value Name: Logging
Value Data (Reg_SZ): voicewarmup

Note that which temp directory the log file is created in depends on the user account under which the Windows Installer transaction was run.  All the relevant information is logged: custom actions, property states, feature states, and error codes.  These can be very helpful in resolving the issue!


Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113