as the topic says you might get that error DSC_E_NO_SUITABLE_CDC also the setup cannot continue since the transport service cannot reach the start state, if you get those errors then diable IPV6 from the registry here is how:
1. Click Start
, type regedit in the Start Search box, and then click regedit.exe in the Programs list.
2. In the User Account Control dialog box, click Continue.
3. In Registry Editor, locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
4. Double-click DisabledComponents to modify the DisabledComponents entry.
Note If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:
1. In the Edit menu, point to New, and then click DWORD (32-bit) Value.
2. Type DisabledComponents, and then press ENTER.
3. Double-click DisabledComponents.
5. Type any one of the following values to configure the IPv6 protocol, and then click OK:
1. Type 0 to enable all IPv6 components.
Note The value "0" is the default setting.
2. Type 0xffffffff to disable all IPv6 components, except the IPv6 loopback interface. This value also configures Windows Vista to use Internet Protocol version 4 (IPv4) instead of IPv6 in prefix policies.
Sunday, May 16, 2010
Wednesday, May 12, 2010
How to configure the WNLB Multicast IP to be routable
as you all know when you configure microsoft WNLB in multicast mode, the IP is not routable from anotehr segments or VLANs thus cannot be reached residing in different VLANs trying to access the IP directly.
some of you might have to run Multicast NLB for one reason or another, to make it routable you will have to be pretty advanced network guys, but not so fancy gears, but here ae the general steps:
1- You need to be running PIM routing
2- Configure an ARP entry for the "unicast ip to multicast mac" 3- relationship on your layer 3 devices.
4- Configure static mac-address-table command that is on the interfaces where servers are conneccted.
5- Disable-snooping.
some of you might have to run Multicast NLB for one reason or another, to make it routable you will have to be pretty advanced network guys, but not so fancy gears, but here ae the general steps:
1- You need to be running PIM routing
2- Configure an ARP entry for the "unicast ip to multicast mac" 3- relationship on your layer 3 devices.
4- Configure static mac-address-table command that is on the interfaces where servers are conneccted.
5- Disable-snooping.
Join Microsoft Egyptian Group (MEGG)
Today we are starting the MEGG,
As you all know there are a lot of Egyptian IT pros, as community is growing either in the virtual community on blogs, forums or in individual basis with no real experiences exchanged.
The idea started with creating a group dedicated for the Egyptian IT community concentrating on Microsoft Technology and others technologies as well and bringing the experience that we all have into one place and in one to one basis.
The idea of MEGG of not bringing a usual IT experiences, we are looking to bring the best Microsoft and IT gurus in Egypt to enhance the community awareness not only from online point of view but also offline and starting delivering sessions and conferences to raise the awareness, bring the latest technologies in house and exchange and experiences in the Egyptian Community.
We are bringing several Technology Experts who will be speaking about Microsoft and IT technology in general including Microsoft Officials, MVPs , Expert Consultants and IT geeks.
you can join our page on Facebook here: http://www.facebook.com/pages/Microsoft-Egyptian-Group-MEGG/116414938397701?ref=mf and know more about the upcoming events and conferences.
More details will be sent to you if you subscribed, please join us since it will be an amazing experience. Please feel free to forward this email to people who might be interested.
As you all know there are a lot of Egyptian IT pros, as community is growing either in the virtual community on blogs, forums or in individual basis with no real experiences exchanged.
The idea started with creating a group dedicated for the Egyptian IT community concentrating on Microsoft Technology and others technologies as well and bringing the experience that we all have into one place and in one to one basis.
The idea of MEGG of not bringing a usual IT experiences, we are looking to bring the best Microsoft and IT gurus in Egypt to enhance the community awareness not only from online point of view but also offline and starting delivering sessions and conferences to raise the awareness, bring the latest technologies in house and exchange and experiences in the Egyptian Community.
We are bringing several Technology Experts who will be speaking about Microsoft and IT technology in general including Microsoft Officials, MVPs , Expert Consultants and IT geeks.
you can join our page on Facebook here: http://www.facebook.com/pages/Microsoft-Egyptian-Group-MEGG/116414938397701?ref=mf and know more about the upcoming events and conferences.
More details will be sent to you if you subscribed, please join us since it will be an amazing experience. Please feel free to forward this email to people who might be interested.
Tuesday, May 11, 2010
Check Point replaced by a Forefront TMG 2010 appliance - solution by a Forefront TMG business partner
Industry Oilfield Services The Solution SecureGUARD TMG950 appliance based on Microsoft Forefront Threat Management Gateway 2010 (TMG) The Microsoft security solution has been expanded by adding the partner's convenient management and support functionalities and deeply integrating them into the customer's Microsoft infrastructure. The ChallengeVAOS Ltd. is a company which specializes in oilfield projects in the inaccessible desert regions of the Sahara. The company headquarters are in Malta and there are branch offices in Linz (Austria) and Libya. A number of smaller branches are also connected. These are mainly located in the middle of the desert, so extreme demands are made on the IT infrastructure too: besides the high temperatures of up to 58° C, there are long distances of hundreds of kilometres between branches and there is no reliable electricity supply or telephone or Internet connection. At all locations, the old solution was to be completely replaced on the basis of Check Point. The small locations were to be connected by satellite. The central administration of the entire solution from the technical location Linz was a very important focus, i.e. implementation of access to distributed Microsoft systems, a distributed Active Directory with 4 domain controllers at four different locations, a distributed Microsoft Exchange mail system with four mail servers, distributed update (Microsoft WSUS) and client deployment (Microsoft Windows Deployment Server) infrastructure at four locations. A VoIP telephone connection to all branches via site-to-site VPN was also asked for, as well as access to the SAP applications (including access from the outside). Of course, IT security had to be guaranteed throughout all connections at all locations. The Technical SolutionThe technical solution was implemented via the security software Forefront Threat Management Gateway 2010 (TMG) from Microsoft integrated into a SecureGUARD TMG950 appliance, which supplements and expands the former by adding management and support functionalities. At the IT headquarters in Linz, a virtualized Microsoft Enterprise Management Server (EMS) has now been installed in addition to a cluster with two nodes. Two SecureGUARD TMG950 appliances are used for the two nodes. The other two large locations at Portomaso and Tripoli are both connected via a TMG950 appliance. The SecureGUARD Starter Edition was sufficient for the smaller locations with their small numbers of users: this is an economical alternative allowing locations with only a few users to be connected as it uses a modified version of the TMG Workgroup Edition. The price is very reasonable due to the limitation to 25 simultaneous users. All branches are connected via site-to-site VPN and are administered centrally from Linz. This is made possible by the "Branch Office Deployment" function of SecureGUARD appliance management in conjunction with the new functionality of the Microsoft Enterprise Management Server in Linz, which permits the central administration of the Standard or Workgroup Edition. The SecureGUARD programmers ensured the communication of customers and suppliers via the enterprise software SAP by using a self-developed NAT driver specially designed for the Microsoft TGM 2010. Comprehensive enterprise security is provided for by the functionalities of the new Microsoft Threat Management Gateway 2010: firewall, antivirus scanning, URL filtering and HTTPS inspection protect all branches. The ResultThe new security functions of the TMG allow the entire administration of the customer to be carried out from one location. Downtimes are minimized as a result of the improved disaster recovery, in which Microsoft integrates a firewall as well as malware and content protection into one unit. On the part of VAOS, this saves personnel resources and a considerable amount of time during operation, thus reducing the costs required for implementing IT security. The functionalities of the SecureGUARD Appliance Management System and of the wizards such as the Branch Office Deployment Wizard guarantee faster software roll-out. Company ProfileSecureGUARD GmbH has its headquarters in Linz and is a leading Austrian manufacturer of high-quality integrated security solutions. All units, from small low-maintenance and low-noise branch office units to redundantly equipped high-performance units with 8 CPU kernels, have the same SecureGUARD functionality. As a Microsoft Gold Certified Partner, SecureGUARD is intensively involved in the development of the Microsoft Forefront Threat Management Gateway (TMG) and the Microsoft Forefront Unified Access Gateway (UAG). With the Microsoft-certified SecureGUARD appliance for Microsoft TMG 2010 and UAG 2010, SecureGUARD combines hardware, software and support to form a high-quality security solution which can be used in particular in homogeneous Microsoft environments with central authentication. For more information, please go to: http://www.secureguard.at Author: : |
FW: CRITICAL UPDATE - Exchange 2010 Address List Segregation and Current Support Stances
Feed: Dgoldman's WebLog
Posted on: Monday, May 10, 2010 8:38 PM
Author: dgoldman
Subject: CRITICAL UPDATE - Exchange 2010 Address List Segregation and Current Support Stances
Back on Wednesday, [January 06, 2010] I published the following blog: Exchange 2010 Address List Segregation – Update. In this blog I made the following statement: "I think you will be happy to know that I am towards the end of wrapping up the Exchange 2010 Address List Segregation white paper. I will post another update as soon as we are finished with the editing and when it will be posted.". After working with development we agreed to post this blog to state a few things:
I need to mention the support stances here.
"It is also important to understand that any attempt to use this whitepaper to configure Exchange 2007 for a commercial "hosting" solution is not supported. This whitepaper is not a replacement for the Microsoft HMC (Hosting and Collaboration) software. The information that is provided in this whitepaper is meant for internal segregation use only." If you are planning on using Exchange 2010 and you currently have Exchange 2007 using Address List segregation *YOU MUST* remove all address list segregation from your organization to avoid running into the bug that we are currently working on at this time. PLEASE HEED THIS WARNING!! In order to revert your organization back to a default exchange installation permission set you can follow this blog: http://blogs.msdn.com/dgoldman/archive/2007/05/16/missing-permissions-on-the-address-lists-container-breaks-the-oab-generation-process.aspx and http://blogs.msdn.com/dgoldman/archive/2008/04/03/how-to-prepare-your-organization-for-exchange-2007-address-list-segregation.aspx I mentioned that I would speak about the nature of this problem. Due to the architectural changes in Exchange 2010, Address Book queries are performed in a different way than we did in prior versions of Exchange. I am not going to explain this in full, however you can view this blog for those new component changes: http://blogs.msdn.com/dgoldman/archive/2010/03/15/exchange-2010-address-list-segregation-update.aspx The problem that I ran in to was that if you already had the deny permission set on the default global address list from using the 2007 Address List segregation white paper and you have installed Exchange 2010 the exchange server will not have the ability to read the default global address list. At this point the default global address list object would be removed from all of the objects showInAddressList attribute. Here is what happens once this occurs:
Your only option to fix this
WARNING: In the event that this does not fix it for any objects in your organization this becomes a manual fix from here. You will need to look up the object that is still having a problem using ADSIEdit.msc and look at the showInAddressList attribute. You will need to add the legacyExchangeDN for the default global address list and this will fix the problem for that object. NOTICE: This blog has been approved by the Microsoft Exchange Product Group. Dave |
Exchange 2010 DAG and Hyper-v Cluster supportability statement - Supported but how
We all have been tought that Exchange 2010 DAG cannot be installed on a hyper-v Cluster or ESX Cluster (generally any hypervisor clustering), this is a correct statement but not entirely true.
the correct statement that Installing Exchange 2010 DAG is not supported on Hypervisor Clustering only when you confiure the VM that hosts the Exchange as highly available machine, thus you control the High availability of he VM using clustering.
if you Install Hyper-v or ESX clustering, you can Install Exchange 2010 DAG normally on a VM that is hosted on any single host of the Hypervisor cluster as long as this machine is not highly available from the Hypervisor point of view meaning that you cannot move it using live migration or Vmotion.
you can now install the DAG on your Hypervisor Cluster physical server normally, don't make the VM highly available, size the IOPs and Memory and you are fine.
Hope that this helps you in your virtualization and Exchange Project
the correct statement that Installing Exchange 2010 DAG is not supported on Hypervisor Clustering only when you confiure the VM that hosts the Exchange as highly available machine, thus you control the High availability of he VM using clustering.
if you Install Hyper-v or ESX clustering, you can Install Exchange 2010 DAG normally on a VM that is hosted on any single host of the Hypervisor cluster as long as this machine is not highly available from the Hypervisor point of view meaning that you cannot move it using live migration or Vmotion.
you can now install the DAG on your Hypervisor Cluster physical server normally, don't make the VM highly available, size the IOPs and Memory and you are fine.
Hope that this helps you in your virtualization and Exchange Project
Monday, May 10, 2010
cannot import or edit certificate in Exchange 2010 - access is denied
Issue:
When you try to edit or import or modify certificate using powershell of EMC you might get the error:
(PID 980, Thread 10) Task Get-ExchangeCertificate writing error when processing record of index 0. Error: Microsoft.Exchange.Data.Common.LocalizedException: The Exchange Certificate operation has failed with an exception. The error message is: Access is denied ---> System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace ---
Solution:
to Fix this issue make sure that the Exchange server is member of the following:
- Exchange Trusted Subsystem group nested in the local admins group on all your CAS/HT boxes.
- Exhachnge servrs are members of this group.
then Restart the servers after any modifications to group membership.
When you try to edit or import or modify certificate using powershell of EMC you might get the error:
(PID 980, Thread 10) Task Get-ExchangeCertificate writing error when processing record of index 0. Error: Microsoft.Exchange.Data.Common.LocalizedException: The Exchange Certificate operation has failed with an exception. The error message is: Access is denied ---> System.ComponentModel.Win32Exception: Access is denied
--- End of inner exception stack trace ---
Solution:
to Fix this issue make sure that the Exchange server is member of the following:
- Exchange Trusted Subsystem group nested in the local admins group on all your CAS/HT boxes.
- Exhachnge servrs are members of this group.
then Restart the servers after any modifications to group membership.
Subscribe to:
Posts (Atom)
