Monday, November 3, 2014

HTC One M8 Windows Phone

I've been a big HTC fan for years, every smart phone I've owned has been HTC, so I was pretty excited about the M8, with it's TV remote features, the sleek design and technical features.  I was even more excited about the fact that it also could come as a windows phone.
I had a windows phone through work about 8 years ago -- pre-iPhone and android, back when blackberry was the major player.  I liked that phone, the push notifications were impressive, there wasn't a touch screen but it also gave you more feature access...I could see network settings and set up a VPN without 3 party downloads.  I was tempted but never jumped in when HTC skinned the old windows phone, and instead went the way of HTC.

I've had the HTC thunderbolt (first 4G LTE phone verizon offered), then the DNA (sleek, fast, but the charging port was easily damaged...I had to use the warranty 3 times, I broke the screen once, got an insurance replacement, then that replacement had to be replaced 3 times before I lost it a few months before my contract came up...the biggest plus was that the battery was encased so they couldn't do the quick battery check for water damage, which was always positive).

I ordered up this phone the first day I was eligible for an early upgrade (you can actually upgrade a month before your contract is up, I'm not sure if it's because I've been with verizon without an issue for 10 years or that's for everyone, but I've been able to do this the past few upgrades).  Of course they sent me the wrong phone -- the M8 with android.  They wanted me to mail it back so they could visually inspect before mailing me a new one.  After waiting months to get this phone there was no way I was going to do that..so I ran out to my nearest Verizon Experience store and did it in person.  They tried to charge me a $35 restocking fee. I threw a minor fit and they waived it.

Got home and cranked it on.  After a simple set up process -- logging onto my live account I was up and running.  After playing for a week I have to say the entire experience is much nicer than android, and from what I've seen from others, iOS.  The integration between applications is much nicer than with Android.  I can configure all my account integration on the microsoft website and my phone immediately knew the changes.

The look and feel of windows is also superior -- in my opinion -- than android.  Everything is more cohesive and makes sense.

The downsides: the live tiles don't work too well, in my opinion.  I can't configure things as well I would like to -- to show more info or get better info.  I'd like more sizing options also, a 4 tile square, for example.

The obvious downside is that there aren't as many apps available.  I went through and checked things before hand and pretty much everything that I used before was still available, so it was an easy change for me.  The apps look different. Twitter has more of the WP style, which is nice, but some of the functionality is slightly different. It takes some getting used to, but even after a few days I like it better.

I'm impressed, and am looking forward to more.

Sunday, October 12, 2014

How to brand MySites

The Default master page/template for MySites in SharePoint is very generic and not at all connected to the rest of the SharePoint farm.  To add some branding (or even a link back to the main portal), you'll have to modify the master page and add a feature stapler.  Here's a great walkthrough I found for setting up a branding feature stapler.

http://sharepointologic.blogspot.com/2013/04/branding-sharepoint-2013-my-sites-with.html

Tuesday, September 30, 2014

Troubleshooting UPS issues

After running into a User Profile Service issue (it was endlessly synchronizing, then when I stopped it it was endlessly stopping) I have the following tips for troubleshooting:

Check the ULS for exceptions, google extensively (I didn't have any exceptions, it just wasn't behaving)
 Then:

  1. Verify Farm Service account and UPS account are in local admins. 
  2. Restart Synchronization service 
  3. Restart IIS 
  4. Restart User Profile manager and Synchronization service 
  5. Restart OWSTIMER.EXE service 
  6. Restart IIS 
  7. Clear File Cache 
  8. Restart all service 
  9. Restart service 
  10. Set fire to office and run 

Usually that'll fix it before step 10, but if not, that's always an option.

Thursday, September 25, 2014

AD FS Claims Rules Deny Caveat

In setting up claims rules to deny groups particular claims, I noticed if I deny the "domain users" group it will deny everyone even if they're not in the "domain users" group.

ADFS 2.1 and SharePoint 2013 Authentication Timeout settings

When using SharePoint with an ADFS 2.1 Trusted Identity Provider, there are several authentication cookies and places where you can set the time outs. After much trial and error, I've discovered how to set it to properly time everything out (so that users aren't logged in perpetually). By default ADFS gives you a cookie that expires after a full month (MSISIPSelectionPersistent) and SharePoint gives you a cookie that expires after a day and a half (FedAuth). When the FedAuth ticket expires it directs you to the trusted identity provider (ADFS). ADFS checks to see if you have that cookie. If so, it logs you back in without asking for credentials. To stop that behavior, change the web.config in the /adfs/ls directory and set the persistIdentityProviderInformation key's enabled property to "false". After that, every time a user is directed to the TIP it will have the user authenticate again. In our environment (SmartCard) this is practically seamless (it just prompts them for their PIN). To lower the amount of time of the FedAuth cookie, go to your SharePoint server and open up the SharePoint Management PowerShell console. use the following: $sts = Get-SPSecurityTokenServiceConfig $sts.CookieLifetime = (New-Timespan -minutes [however long you want the cookie to last in minutes]) $sts.Update() iisreset The next time users have to check in they'll get the new cookies and timeout settings.

Wednesday, August 27, 2014

AD FS Service Account Permissions and Rights, Initial Configuration Notes

The initial configuration of AD FS (at least for v3.0) has to be performed with a domain administrator account.

 The service account that runs AD FS must have rights on the local server to:

Log in as a batch job
Generate Audit Logs

Friday, August 8, 2014

Crazy ASP.net error

We deployed an asp.net 4.0 site, ran all the SQL scripts and cranked it up. The first visit to the site: Page cannot be displayed. This was on windows 2008 (IIS 7) so there was no web service extensions that needed to be enabled. I registered asp.net v4 again, still no joy. The application log was flooded with errors: Event ID: 1000 Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: Faulting module name: clr.dll, version: 4.0.30319.18444, time stame: Exception code: 0xc00000fd Faulting process id: 0xb9c Faulting application start time : faulting application path: c:\Windows\SysWOW64\inetsrv\w3wp.exe faulting module path: c:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll The site served HTML pages, but anything .aspx it crashed on with the above error. When I changed the app pool identity it crashed with an asp.net error if the identity wasn't in the iis_iusrs group. If we made a change to the web.config that invalidated the web.config it would present an asp.net error. Based on all this I knew that asp.net was working and the IIS was working. It had to be a problem in the code. Looking at the code we found that application_start did a SQL server call. Upon further investigation it turns out that a SQL script the devs ran stripped the permissions from the database user the site was using. Promoting that user to have owner privileges on that database resolved the issue. The moral: crashes in the application_start don't present a good error message. If you have the code and it's acting funny like this look at that to see where the problem could be happening. Additionally, always always verify the expected accounts have proper permissions at all levels even if your head tells you things like: "it shouldn't be accessing the SQL server yet."