The Psychological & Technological Blog
Archive for March 2010
I have worked some people that have hashed out their own home-grown app to take installation screenshots. Wink by this guy at DebugMode is by far the easiest and most robust implementation I have found and used so far.
Being able to export screenshots to PDF is great.
So far I’ve been using this for documenting software installations, troubleshooting, and realtime capturing of changes in controlled environments.
This has recently become a perplexing issue in our Project 2007 environment. I found that the aligning a project to a cube could be done from the server, so that proved that everything was ‘working’ to some degree. however, when attempting to modify these server setting views from a remote workstation, the title of this post would greet me in red.
Despite some recommendations to add this url to the Trusted Sites zone, there is no need to do so. You should add the url of your project server to the intranet zone, and ensure that comms across domains is allowed for that zone (this is about halfway down the custom settings menu under the security tab). Adding the SQL Server Analysis Server in to the list is not necessary.
The intranet zone? Why? Because all you end up doing by using the trusted sites zone is recreating your intranet zone settings.
It was this guys post which directed me to the ‘missing link’ download which resolved this issue. The drawback – it must be installed on each workstation to utilize Project Web Access. The bonus, it’s already in MSI packaging ready to be deployed via your AD/SMS/etc
The package I required (I already had the office web access and XML) was the Install Microsoft SQL Server 2005 Analysis Services 9.0 OLE DB Provider, can be downloaded from here
I was recently asked a number of questions about implementing moss in a public facing environment, and how to best secure the highly sensitive data which will be accessed through the portal.
In hindsight, I found the person had already made their mind up on the best approach for the security architecture either through their own personal experience of other secured systems, or from what somebody told them.
What this person was after, was a way to take a single dedicated service account (meaning a single application pool I presume), to handle multiple public facing logins securely, so that if the service account was ever breached, there would be no access to confidential data.
It seemed that after politely explaining that this holy grail is not possible if the public front-end remains available for anyone in the world to attempt a login, there had to be additional security approaches such as Kerberos, smart cards, or providing a stripped down read-only aspect of non-sensitive information.
If there is a way to achieve these requirement as mentioned above, please do share as I’d be most interested to understand how MOSS 2007 can accomodate this strategy.
Upon reflecting this a bit further, I could have better explained that introducing Portal to the public, there are mandatory requirements that further expose the most service if you want to allow logins to some degree. With access mappings, those potential breaches can be kept to a minimum. For each WFE, there are multiple services, or at least application pools to consider for access to the backend databases…
Some additional sites/blogs that seem close to explaining this in a general manner:
http://cregan.wordpress.com/2006/12/08/moss-setup-service-accounts/
http://blog.tomaselfving.com/2008/01/security-features-in-moss-2007.html
This guy has a nice post on what I am getting at:
http://www.winblogs.net/index.php/2009/09/30/a-few-powershell-useful-tricks/
Where I take mine a little further, is that I’ll run this command either on a temp drive or a UNC path for interrogating logs on remote servers:
cat “\\servername\c$\Program Files\iis\w3xxxx.log” | findstr interestingString
in more recent versions of the RDP software, the switch has changed from /console, to /admin. give that a try and all should be fine for those all-important console sessions via RDP.
mstsc /v:servername /admin
Thanks to this guy and his blog for the solution:
http://www.lehmkuhl.za.net/blog/post/2008/08/19/MSTSC-console-not-working-anymore.aspx