We are about to image the district with Windows 8.1 Enterprise. I’ve been tweaking my Windows 8.1 image all week and have learned a lot that I will blog about later. One of the main objectives with our Windows 8.1 deployment is to hide or obscure the concept of apps in Windows 8 without actually restricting their use.
One method we are using is a default start menu with only desktop apps listed. This is already blogged about on many sites. Google for Export-StartLayout and you’ll find what you are looking for. Now that our start menu is “app-free”, I needed to tackle the Apps View. By default, Apps are listed first. Luckily, there is a Group Policy in Windows 8.1 which allows you to “List desktop apps first in the apps view” located at User Configuration/Policies/Administrative Templates/Start Menu and Task Bar. Unfortunately, this only works when the Apps View is sorted by category and by default, the Apps View is sorted by name.
Surely, this has to be a registry key. I head out to http://live.sysinternals.com to download Procmon.exe, change the Apps View sort setting and out pops a nice little registry key named LauncherSortOption located at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\Grid in the registry. This DWORD accepts the following values:
0 – Sort by Name
1 – Sort by Date
2 – Sort by Most Used
3 – Sort by Category
Create a Group Policy Preference for that registry key, set it to 3 and my problem is solved. Windows 8.1, here we come.
I’m still in the stage of migrating to SharePoint 2013. As a preparatory step, I uninstalled SPD 2010 and installed SPD2013 as SharePoint 2013 requires SPD 2013. At some point in the migration, I had to update a SPD2010 workflow. Guess what? SPD2013 isn’t compatible with SharePoint 2010. So I reinstalled SPD 2010 but every time I click the Open Site button, it crashes.
Luckily, I still had the Recent Sites list so I could still use the tool, I just had to start at the root site and navigate my way down. After a month of “dealing with it”, I asked Google for an answer. Luckily, someone else already went through the tough work of diagnosing the problem and offering a solution. His case is the reverse of mine (he probably didn’t uninstall SPD2010 first) but the resolution is the same.
Delete the ClientGUID keys (both of them) to resolve the issue.
Here you go: http://sympmarc.com/2013/04/16/sharepoint-designer-2013-crashing-on-open-site-the-fix/
In our network, we manage most IP addresses with DHCP reservations, servers, printers, video cameras, security panels etc.. about the only thing that doesn’t have DHCP reservations are workstations/laptops/devices etc..
I’ve always considered our single DHCP server a weakness as a single point of failure, and it has been (especially if you delete all of your reservations! Hey, it happened). Until Windows Server 2012, the best you could do was to split your DHCP scopes between two or more DHCP servers. The weakness of this approach is that your scopes need to be large enough to support a failure scenario, otherwise you can only support half of your devices (depending on the length and knowledge of your failure) and you still are susceptible of losing your DHCP reservations.
Worry no more. Windows Server 2012 supports true DHCP fail-over. We haven’t actually implemented it yet but will soon. We are in the process of moving to a full virtualized infrastructure with a DC being on of my only physical machines. For reasons that only make sense in my brain, I will probably move our primary DHCP to a physical server as well (or co-locate on the DC) and have the fail-over DHCP running in our Hyper-V cluster.
Here is a link from Microsoft explaining how to configure this setup:
DHCP Fail-over in Windows Server 2012
Taken from http://austintovey.blogspot.com/2012/04/optimal-iscsi-nic-settings.html
Optimal iSCSI NIC settings
This can help eliminate TCP retransmits between EQL and the host.Find the 2x iSCSI NICs in the registry, only change this for NICs connecting to iSCSI storage.
Create two new DWORDS
TcpAckFrequency = 1
TcpDelAckTicks = 0
Restart the server.
After updating to HIT Kit 4.5 on a 2008 R2 server, I tried to configure the PS Group Access and it kept timing out waiting for the ASM Agent. A simple reboot solved the problem.
Arrgg! My Exchange 2013 migration was going so well until I added a new receive connector to enable a secure relay for our copiers etc..I added another IP to the internal NIC to handle this duty.
I made the change Wednesday night and didn’t notice anything wrong until Thursday morning when people started calling asking what’s up with the email. I started troubleshooting with my analyst while driving the 30 minute trip and tried the usual suspects. Check the queues, building up. Reboot, no help. Finally check the event viewer and notice the MSExchangeSubmission.exe is crashing repeatedly. Stumped at this point so I undid the change made the night before.
Check the queues again and notice they are failing on a DNS failure. Huh? I have no problems with my DNS servers, why can’t it resolve DNS queries. Command prompt: ping google.com…100% success rate. ping …0% success rate.
Check DNS, the server is listed and has the correct IP address. Getting frustrated now. Modified the hosts file and added the server/ip combo in it and everything is magically better. A couple hours later with everything running smooth, I decided to add my receive connector IP address back onto the NIC. Head into a meeting and start getting calls again. Remove the IP and everything works again. Later that night, added the IP back and everything craps out. Long story short, this is a bug in Exchange 2013 somewhere that prevents it from detecting the NIC dns settings when you add a secondary IP to the NIC. Quick fix is to specify the DNS settings in Exchange (I used my internal dns for External DNS and Internal DNS) as viewed in the screenshot above.
Other than that, I migrated Public Folders today and shutdown my Exchange 2010 servers…so far so good.