When you select the Assigned To drop down in a TFS work item, you’ll often see a lot of system accounts that you don’t want. Nikos’ post on TFS 2008 still works for TFS 2010 with the Power Tools. Previously, I was exporting the XML, editing it, and then re-imported based on Edward Smit’s post and several other forums but once I found Nikos’ post I’ve started just updating it direct with the Power Tools. I wanted to filter by the Project Administrators and Contributors groups.
I also wanted the ability to “unassign” a task after it had been assigned to a user. If there’s an easy way to set a work item back “nothing” for the assigned user after it’s been assigned, I don’t know it. But this is an easy work around. Create a user called Unassigned and then we just set it to that when we want to let them team know it’s currently unassigned. Here’s the steps…
That should do it. Refresh you Team Project and now open the work item of the type you edited and the Assigned To should be filtered now and should include the option to set it Unassigned.
If you’re setting up a UC560, there’s times when you just want to start over (especially if you’ve made changes with the CLI). There’s a great post by John Platts with the steps so all credit to John but I thought I’d also put them here as well.
Once the UC500 is rebooted, it’s back to default and you can connect via IP as usual to the default IP for your unit.
Personally, I like Outlook 2010 a lot but it does take some getting use to first. On a new setup, here’s a couple of things I change right away to suit my needs.
Tip #1 Change Reading Pane to bottom
This one is pretty easy and know some people use it on the side. But I like to see the columns with date and size so putting the reading pane on the bottom works much better for me. For this just click the View tab at the top and you’ll see in the Layout section Reading Pane with a down arrow. Just click the down arrow and select Bottom.
Tip #2 Mark email as read if viewed for 3 seconds
Since we read most emails in the preview Reading Pane, I also like to change it so the email is marked as read if I look at that email for 3 seconds. To make that change:
Tip #3: After moving or deleting an email, move up
The other big one for me is after I delete an email, I want my selection to move Up, not Down. I generally read emails from the bottom starting with the oldest so if I delete or move and email I want to then move on to the one above. Here’s how:
So not the most glamorous or amazing tips but key tips for me and at least one is not in an obvious place to look…at least not to me. :)
Not sure what started it, but my Visual Studio projects stopped building with this error:
This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.
Others could build the code fine so that made it “my problem”. While banging my head on the wall, another application we use that’s really a web based app wrapped in a desktop app quite working. It would just give an unhandle exception error and say “System.InvalidOperationException” error. On a whim, I decided to let it debug and that fired up Visual Studio 2010. To my suprise, there was the same FIPS error. Now I had a root cause for both my issues which let me to Raj Rao’s post. It was an old post (2007) but it got me going. Other MS KB’s were related to .Net 2.0 and ASP.net apps so I was at a lose so I gave it a shot. Following Raj’s post, here’s what I did…
I changed that setting to Disabled and everything started to work…didn’t even require a restart. The default for that setting is Disabled so what enabled it I have no idea. I didn’t need it so my researched ended there.
We replaced a single TMG 2010 server with a pair of TMG 2010 servers using NLB for internal and external NIC’s. That process in itself was somewhat of a challenge. Along the way we found a bug that was introduced in TMG 2010 SP1. On the single server (non SP1), we had a HTTP listener using a custom port of 8080 (this was for TFS just so you know). On the new servers, we added SP1 for TMG 2010 before adding any rules and then tried to add the HTTP listener on port 8080. However, in the listener properties, as soon as we change the HTTP port and tried to apply we received this error: “This Web Listener is configured to use SSL. You must specify a certificate for use in this Web Listener.”
You can duplicate this by simply creating a new listener, click on the Connections tab, change HTTP port to anything other than 80 and try to apply as shown below.
After seeing the error you may notice that without SP1, the Certificates tab will have all it’s options disabled if you don’t check Enable SSL on the Connections tab. However, after applying SP1 those options on the Certificates tab are not getting disabled and I guess there’s code that keys off that resulting in the erroneous error message we received.
We opened a case with Microsoft and it was confirmed that this is a issue introduced with TMG 2010 SP1 and they are working on a fix. Currently, I see two workarounds:
So there you have it. Just select any SSL cert to get you going even though you may be adding a non-SSL rule/listener. I hope this saves you some time and headache.
After you install TMG 2010 on a server, you’ll probably notice that Windows Update no longer works giving error 80072EE2.
The fix is to set you Internet Explorer proxy setting to point to TMG on port 8080. You probably know the steps but just in case, here’s what you need to do:
You should be able to run Windows Updates now without any problem. Not sure I totally understand why that’s required for Windows Update since if you allow Localhost to External, you can browse the Internet just fine without adding TMG as your proxy server. If anyone knows why it effects Windows Update, let me know.
By default, installing SQL Server 2008 R2 on a brand new Windows Server 2008 R2 server does not open the required Windows Firewall port. I always wonder why they don't give you the option and install to have MS make the changes for you. At any rate, MS has a tool to "Fix It" but on my Windows Server 2008 R2 it ran but said it didn't apply to my setup. ????
You can of course follow Microsoft's KB articles and manually add the Windows Advanced Firewall rules. For me, a script to do this was the way to go. Rolly Perreaux had a great post on setting up SQL and he had the script I've been using to open all SQL ports for my Domain profile on SQL servers. Here's that script.
@echo *** OPENING SQL SERVER PORTS ***
netsh advfirewall firewall add rule name="SQL Server (TCP 1433)" dir=in action=allow protocol=TCP localport=1433 profile=domain
netsh advfirewall firewall add rule name="SQL Admin Connection (TCP 1434)" dir=in action=allow protocol=TCP localport=1434 profile=domain
netsh advfirewall firewall add rule name="SQL Service Broker (TCP 4022)" dir=in action=allow protocol=TCP localport=4022 profile=domain
netsh advfirewall firewall add rule name="SQL Debugger/RPC (TCP 135)" dir=in action=allow protocol=TCP localport=135 profile=domain
netsh advfirewall firewall add rule name="SQL Browser (UDP 1434)" dir=in action=allow protocol=UDP localport=1434 profile=domain
@echo *** OPENING ANALYSIS SERVICES PORTS ***
netsh advfirewall firewall add rule name="Analysis Services (TCP 2383)" dir=in action=allow protocol=TCP localport=2383 profile=domain
netsh advfirewall firewall add rule name="SQL Browser (TCP 2382)" dir=in action=allow protocol=TCP localport=2382 profile=domain
@echo *** OPENING WEB SERVER PORTS ***
netsh advfirewall firewall add rule name="Web Server HTTP (TCP 80)" dir=in action=allow protocol=TCP localport=80 profile=domain
netsh advfirewall firewall add rule name="Web Server SSL (TCP 443)" dir=in action=allow protocol=TCP localport=443 profile=domain
After installing the seemingly harmless Security Update for Windows SharePoint Services 3.0 x64(KB9834444) update on a SBS 2008 server, users complained the next day that they couldn't open CompanyWeb. They would receive the error "Cannot connect to the configuration database." In short, the fix was to re-run the Configuring Sharepoint Products and Technologies Wizard. As soon as we kicked that off we received the message that there were new files that needed to be updated so obviously something needed to get upgraded that the Windows Update process didn't handle. Seems like the kind of thing that should have received a pop-up of some sort during the Windows Update install.
At any rate, re-running the Configuring Sharepoint Products and Technologies Wizard in Administrative Tools fixed the issue.
One of the issues with the "cloud" world is most apps are hosted using SSL for security. This means your URL is their URL. For instance, Microsoft Online (BPOS) will use https://red001.mail.microsoftonline.com for OWA for North America. If you just add a CNAME entry in DNS, that will redirect traffic but you'll get an SSL error since the names don't match. For instance, redirecting .com">.com">https://owa.<yourdomain>.com to https://red001.mail.microsoftonline.com will sort of work but with the SSL error so it's ugly.
In the past I'd setup IIS pages that would just redirect http traffic to the https URL I wanted but that's a pain to setup each time. With TMG 2010 (and really ISA 2006 also I believe), you can just deny that traffic and then redirect it to any URL you'd like. Here's the steps to redirect in TMG 2010.
Here’s a screen shot of how I redirect OWA to BPOS.
Now when you browse to http://<initialURL> that traffic will be redirected to https://<targetURL>. That'll at least give your users an easy initial URL to remember. It won't hide that target URL which can be a shame in certain scenarios. If the site just users HTTP, then CNAME records work great for that but as I mentioned before that'll give ugly verification errors for HTTPS.
We recently set up a one-way trust between two domains. Some admins however were unable to make RDP connections to the servers in the trusting domain even though they were in a group that was part of the administrators group on the local servers. After providing login credentials to domain A, they'd get authenticated and begin to login to comptuters in domain B only to get this error:
Logon Failure: The machine you are logging onto is protected by an authentication firewall. The specified account is not allowed to authenticate to the machine
This error is occuring because we set up a "selective authentication" when we created our one-way trust. We did that deliberately as we wanted to do just that and selectively allow access to resources in domain B. Here's the fix...
That should get you going!