Group Managed Service Accounts, Scheduled Tasks, Monthly Schedules

Not sure if this is a weird bug, or intended feature in windows….

 

You can automate the creation of non PowerShell defined scheduled task triggers (i.e. the first day or every month) with an XML file and register the task with that...however this scheduled task cannot run as a group managed service account.

You can only run scheduled tasks, as a group managed service account, with trigger parameters that are defined in PowerShell only..as a work around, run the task daily, and modify the PowerShell to check to see if it is the 1^st of the month, and if not, to abort.

Lync 2010 Response Groups not working after adding Lync 2013 Front End server

I was migrating Lync at my office from 2010 to 2013, and after the first Front End server was added to the new 2013 Lync pool I ran into a precarious issue. The issue was that users could call into the IVR but never made it to a help desk technician. After troubleshooting, I narrowed the issue down specifically to response groups were behaving like the agents were not actually a member. An entire weekend of troubleshooting later and I found that the response groups were trying to contact older SIP addresses for the agents. Several months ago, I added an additional SIP domain <externaldomain.com> to the list, and changed over the SIP address of the users. The Response Groups seem to be referencing the old SIP address of the agents. I created distribution groups to represent the membership, and then changes the response groups to use the distribution instead of the custom list. This seemed to fix the issue, and the response groups were working again.

Cannot connect Clustered SQL Server 2012 SP1 Analysis Services

While deploying a System Center 2012 R2 Service Manager data warehouse server I noticed that I could no longer connection to the clustered 2012 SP1 SQL Analysis Services. Twenty four hours of troubleshooting later, it was because the SQL browser service on each cluster node was returning an IPv6 TCP port for the Analysis Service Instance. I am not actively using IPv6 in this scenario. The configuration file is stored here:

\Program Files (x86)\Microsoft SQL Server\90\Shared\ASConfig\msmdredir.ini

I stopped the SQL Server Analysis Service from the Failover Cluster Manager, and removed this line from the ini file: 

<PortIPv6>xxxxx</PortIPv6>. 

I repeated this step on the other cluster nodes, and then started the service from the FCM I could then connect with SSMS, and the SCSM DW installation wizard continued.

Quickbooks Enterprise 14 Silent Install with MDT

This is setup for MDT targeting Windows 8.1 deployment. Note that inside the installation sequence for the workstations I am turning on the Windows Features for all versions of .NET. This version of QB requires .NET 4.0, and since it is part of the operating system I did not have to add a package to the application bundle. If you are deploying to Windows 7 then obviously you will have to handle .NET yourself.

Create an application bundle, with these items, in this sequence
1. MSXML6 x64
2. MSXML6 x86
3. Visual C++ 2008 x86 9.0.30729.17
4. QB Runtime Redistributable
5. QB VC10 Debug
6. Amyuni PDF Printer 412
7. Quickbooks Enterprise 14

Open up the .exe installer with 7zip or some other archive tool.
Item 1. MSXML6 x64
Executable String: msiexec /qn /i "msxml6_x64.msi" REBOOT=REALLYSUPPRESS
Location: found inside Thirdparty\MSXML6

Item 2. MSXML6 x86
Executable String: msiexec /qn /i "msxml6_x86.msi" REBOOT=REALLYSUPPRESS
Location: found inside Thirdparty\MSXML6

Item 3. Visual C++ 2008 x86 9.0.30729.17

Executable String: msiexec /qn /i "vc_red.msi" REBOOT=REALLYSUPPRESS
Location: found inside Thirdparty\CRT9
Note: I also included the vc_red.cab file in the folder during the application import.

Item 4: QB Runtime Redistributable
Location: found inside thirdparty\CRT10
Note: I had to capture the MSI file called "Quickbooks Runtime Redistributable.msi" from the executable. It extracts to c:\users\current*user\appdata\local\temp\random*folder.
Executable String: msiexec /qn /i "Quickbooks Runtime Redistributable.msi" REBOOT=REALLYSUPPRESS

Item 5. QB VC10 Debug
Location: found inside thirdparty\CRT10
Note: I got the MSI file called "QuickBooks_VC10_Debug.msi" the same way as Item 4.
Executable String: msiexec /qn /i "QuickBooks_VC10_Debug.msi" REBOOT=REALLYSUPPRESS

Item 6. The Amyuni PDF Printer:
Location: Executable under thirdparty\ABS
Executable String: ABSPDF4123Setup.exe /s

Item 7, this msiexec command has quite a few properties.
Note: Included the entire \Qbooks folder during the application import. Substitute your license and product number into the string listed below.

Executable String: msiexec /qn /i "quickbooks.msi" INSTALLMANAGER=1 REBOOT=S INSTALLDIR="C:\Program Files (x86)\Intuit\QuickBooks Enterprise Solutions 14.0"  QB_LICENSENUM=YOUR-LICENSE-NUM QB_PRODUCTNUM=YOUR-PRODUCT-NUM UNIQUE_NAME=bel   ISW_LICENSENUM= ISW_PRODUCTNUM=   INSTALLDESKTOPICONS=1   QB_DBR_SETHOST=0   QB_IS_SUBSCRIPTION=0  PARENTAPP=INSTALLMANAGER

Have fun and happy deployments!

Xen Server Rolling Pool Upgrade HTTP invalid url to installer files

Problem with the "invalid url to installer files" error while attempting a rolling pool upgrade. The web server was IIS 8. The problem was that a mime type for the empty extension was not defined. Solved by creating a new mime type of "." [actually type a period and nothing else into the text box] with type "application/octet-stream". You also need to have a mime type for bz2 and possibly more. I simply created a mime type of "application/octet-stream" for extensions ".*" to include all corner cases. This resolved the 404 error and Xen Center could now see the install files on the website.

Xenserver: Deleting VDIs locked by the control domain

You can run into a situation where during a canceled move, a VDI is created on a SR that is locked by the control domain, even after a reboot.

Here is the method I used to solve this situation: 

1. Find the UUID of the VDI: xe vdi-list name-label = <Name of the VDI>
2. Find the UUID of the block device that the VDI is mounted with: xe vbd-list vdi-uuid=<UUID of the VDI>
3. Unplug the block device, this will corrupt the VDI: xe vbd-unplug uuid=<UUID of the block device>
4. Make the control domain forget the vdi: xe vdi-forget uuid=<UUID of the VDI>
5. Rescan the SR: xe vdi-scan sr-uuid=<UUID of the SR>
6. Destroy the VDI file: xe vdi-destroy uuid=<UUID of the VDI>

Journey into the Microsoft Private Cloud

The HP c7000 blade server chassis arrived today. Join me as I construct our Private Cloud, leveraging Microsoft System Center over the next month.

Update: Hardware installed, but the migration project has been put on hold until I can carve out budget for HP Virtual Connect modules.